<?xml version="1.0" encoding="utf-8"?>
<vulnerabilities xmlns="http://tempuri.org/XMLSchemaOptions.xsd">

<vuln_items>wasc_1</vuln_items>
<vuln_item_wasc_1>
	<alert>Недостаточная аутентификация </alert>
	<desc>Недостаточная проверка подлинности происходит, когда веб-сайт позволяет злоумышленнику получить доступ к конфиденциальному содержимому или функциональности без необходимости надлежащей проверки подлинности. Веб-инструменты администрирования являются хорошим примером веб-сайтов, предоставляющих доступ к конфиденциальным функциям. В зависимости от конкретного интернет-ресурса эти веб-приложения не должны быть доступны напрямую, не требуя от пользователя надлежащей проверки его личности.

Чтобы обойти настройку аутентификации, некоторые ресурсы защищены "скрытием" определенного местоположения и не связывают расположение в основной веб-сайт или другие общественные места. Однако, такой подход-не более чем "Безопасность Через Неизвестность". Важно понимать что несмотря на то что ресурс неизвестен злоумышленнику, он по-прежнему остается доступным непосредственно через определенный URL-адрес. Конкретный URL-адрес может быть обнаружен с помощью зондирования грубой силы для общих расположений файлов и каталогов (/admin для образец), Сообщений об ошибках, журналов ссылок или документации, таких как файлы справки. Эти ресурсы, независимо от того управляются ли они контентом или функциональностью, должны быть надлежащим образом защищены.</desc>
	<solution>Фаза: Архитектура и дизайн
Использовать систему проверки подлинности или библиотеки такие как средство проверки подлинности сообщество owasp ESAPI.</solution>
	<reference>http://projects.webappsec.org/Insufficient-Authentication</reference>
	<reference>http://cwe.mitre.org/data/definitions/287.html</reference>
	<reference>http://cwe.mitre.org/data/definitions/284.html</reference>
</vuln_item_wasc_1>

<vuln_items>wasc_2</vuln_items>
<vuln_item_wasc_2>
	<alert>Недостаточная Авторизация</alert>
	<desc>Недостаточная авторизация приводит к тому что приложение не выполняет адекватные проверки авторизации чтобы убедиться что пользователь выполняет функцию или доступ к данным в соответствии с политикой безопасности. Процедуры авторизации должны обеспечивать выполнение допустимых действий пользователя службы или приложения. Когда пользователь проходит проверку подлинности на веб-сайте это не обязательно означает что пользователь должен иметь полный доступ ко всему содержимому и функциональности.

Недостаточная Авторизация Функции

Многие приложения предоставляют различные функциональные возможности различным пользователям. Новостной сайт позволяет пользователям просматривать новости но не публиковать их. Система учета будет иметь разные разрешения для сотрудника по расчетам с поставщиками и сотрудника по дебиторской задолженности. Недостаточная авторизация функций происходит когда приложение не запрещает пользователям получать доступ к функциям приложения в нарушение политики безопасности.

Очень наглядным примером является хак 2005 года процесса подачи заявок Гарвардской школы бизнеса. Сбой авторизации позволил пользователям просматривать свои собственные данные когда им не должен был быть разрешен доступ к этой части веб-сайта.
 
Недостаточная Авторизация Данных

Многие приложения предоставляют базовые идентификаторы данных в URL-адресе. Например при доступе к медицинской записи в системе может быть URL-адрес, такой как:

http://example.com/RecordView?id=12345

Если приложение не проверяет имеет ли удостоверенный идентификатор пользователя права на чтение, затем он может отображать данные пользователя которые пользователь не должен видеть.

Nsufficient данные для авторизации является более распространенным чем недостаточная функция авторизации, потому что программисты как правило имеют полное представление о функциональности приложения, но не всегда есть полное сопоставление всех данных к которым приложение будет иметь доступ. Программисты часто имеют жесткий контроль над механизмами авторизации функций, но полагаться на другие системы такие как базы данных для выполнения авторизации данных.</desc>
	<solution>Фазы: Архитектура и дизайн; Операция
Очень тщательно управляйте настройкой, управление, и обращение с привилегиями. Явное управление доверительными зонами в программном обеспечении.

Фаза: Архитектура и дизайн 
Обеспечить надлежащее разделение заложено в конструкцию системы и что обособление служит для возможности и для дальнейшего укрепления привилегия разделению функционала. Архитекторы и дизайнеры должны полагаться на принцип наименьших привилегий чтобы решить когда это целесообразно использовать и отказаться от системных привилегий.</solution>
	<reference>http://projects.webappsec.org/Insufficient-Authorization</reference>
	<reference>http://cwe.mitre.org/data/definitions/284.html</reference>
	<reference>http://cwe.mitre.org/data/definitions/285.html</reference>
</vuln_item_wasc_2>

<vuln_items>wasc_3</vuln_items>
<vuln_item_wasc_3>
	<alert>Целочисленное переполнение</alert>
	<desc>Целочисленное переполнение-это условие которое возникает 
когда результат арифметической операции, как умножение или добавление, превышает максимальный размер целочисленного типа используемого для его хранения. При переполнении целого числа, измеренное значение появится "обернутые вокруг” максимальное значение и снова запускается при минимальном значении, подобно часам которые представляют 13: 00, указывая на 1: 00.

Например, 8-разрядное целое число со знаком на большинстве распространенных компьютерных архитектур имеет максимальное значение 127 и минимальное -128. Если программист сохраняет значение 127 в такой переменной и добавляет к ней 1, результат должен быть 128. Однако, это значение превышает максимальное для этого целочисленного типа, таким образом интерпретируемое значение "обернется" и станет -128.</desc>
	<solution>Фаза: Требования
Убедитесь что все протоколы строго определены, таким образом, что все вне границ поведение может быть идентифицировано просто, и требуют точного соблюдения протокола.

Этап: Требования
Используйте язык который не допускает возникновения этой слабости или предоставляет конструкции которые делают эту слабость легче избежать.
Если можно, выберите язык или компилятор выполняющий автоматическую проверку границ.

Этап: Архитектура и дизайн
Используйте проверенную библиотеку или платформу которая не позволяет этому недостатку возникать или предоставляет конструкции которые делают эту слабость легче избежать.
Используйте библиотеки или платформы которые облегчают обработку чисел без непредвиденных последствий.
Примеры включают безопасный целое обработку пакетов, таких как SafeInt (C++) или IntegerLib (C или C++).

Фаза: Реализация
Выполните проверку ввода для любого числового ввода, гарантируя что он находится в пределах ожидаемого диапазона. Убедитесь что входные данные соответствуют минимальным и максимальным требованиям для ожидаемого диапазона.
По возможности используйте целые числа без знака. Это облегчает выполнение проверок правильности для переполнения целых чисел. Если необходимо использовать целые числа со знаком, убедитесь что проверка диапазона включает как минимальные так и максимальные значения.

Фаза: Implementation
Understand your programming language's underlying representation and how it interacts with numeric calculation (CWE-681). Обратите пристальное внимание на несоответствия размера байта, точность, подписанные/неподписанные различия, усечение, преобразование и приведение типов, ''не-число'' проведенные расчеты, и как ваш язык обрабатывает номера которые слишком велики или слишком малы для его базового представления.
Также будьте осторожны чтобы учитывать 32-бит, 64-битовый, и другие отличия которые могут повлиять на числовое представление.

Фаза: Реализация
Внимательно изучите предупреждения и ликвидации возможных серьезных проблем, например несоответствие подписанных / неподписанных. Даже если слабость редко эксплуатируется, один сбой может привести к компрометации всей системы.</solution>
	<reference>http://projects.webappsec.org/Integer-Overflows</reference>
	<reference>http://cwe.mitre.org/data/definitions/190.html</reference>
</vuln_item_wasc_3>

<vuln_items>wasc_4</vuln_items>
<vuln_item_wasc_4>
	<alert>Недостаточная Защита Транспортного Слоя</alert>
	<desc>Недостаточная Защита Транспортного Слоя
Недостаточная защита транспортного уровня позволяет связи подвергаться ненадежным третьи-страны, предоставление вектора атаки для компрометации веб-приложения и/или кражи конфиденциальной информации. Веб-сайты обычно используют протокол защищенных Сокетов / Транспорт слой безопасности (SSL/TLS) для обеспечения шифрования на транспортном уровне. Однако, если веб-сайт не настроен на использование SSL/TLS и настроен на использование SSL/TLS должным образом, сайт может быть уязвим для перехвата и модификации.
 
Отсутствие шифрования транспортного уровня
Если транспортный уровень не зашифрован, ll связь между веб-сайтом и клиентом отправляется четкий-текст который оставляет его открытым для перехвата, инъекция и перенаправление (также известный как человек-в-тот-средний/aтака MITM). Злоумышленник может пассивно перехватить сообщение, предоставление им доступа к любым передаваемым конфиденциальным данным таким как имена пользователей и пароли. Злоумышленник также может активно внедрение/удаление содержимого из сообщения, разрешение злоумышленнику подделывать и пропускать информацию, вредоносных скриптов, или вызвать клиент для доступа к удаленному недоверенному содержимому. Злоумышленник также может перенаправить сообщение таким образом чтобы веб-сайт и клиент больше не общались друг с другом, но вместо этого неосознанно общаются с злоумышленником в контексте другой доверенной стороны.

Слабая Поддержка Шифра
Исторически, высокая криптография класса была ограничена от экспорта за пределы Соединенных Штатов. Поэтому, веб-сайты были настроены для поддержки слабых криптографических опций для тех клиентов которые были ограничены только использованием слабых шифров. Слабые шифры уязвимы для атак из-за относительной легкости их взлома; 
менее двух недель на обычном домашнем компьютере и несколько секунд с использованием выделенного оборудования.
Сегодняшний день, все современные браузеры и веб сайты используют гораздо более сильное шифрование, но некоторые веб сайты по прежнему настроены для поддержки устаревших слабых шифров. Поэтому, злоумышленник может заставить клиента перейти на более слабый шифр при подключении к веб сайту, позволяет злоумышленнику сломать слабое шифрование. По этой причине, сервер должен быть настроен чтобы только принимать сильные шифры и не предоставлять сервис любому клиенту который запрашивает использование более слабого шифра. Кроме того, некоторые веб сайты неправильно настроены для выбора более слабого шифра даже если клиент будет поддерживать гораздо более сильный. OWASP предлагает руководство по тестированию проблем SSL/TLS, включая слабую поддержку шифров и неверную конфигурацию, и есть и другие ресурсы и инструменты.</desc>
	<solution>Фаза: Требования
Четко укажите какие данные или ресурсы являются достаточно ценными чтобы их можно было защитить с помощью шифрования. Требовать чтобы любая передача или хранение этих данных/ресурсов использовали хорошо проверенные алгоритмы шифрования.

Фаза: Архитектура и дизайн
Использование моделирования угроз или других методов, предположим что ваши данные могут быть скомпрометированы через отдельную Уязвимость или слабость, и определить где шифрование будет наиболее эффективным. Убедитесь что данные которые по вашему мнению должны быть частными не подвергаются непреднамеренному воздействию с использованием таких слабых мест как небезопасные разрешения (CWE-732).

Фаза: Архитектура и дизайн
Убедитесь что шифрование правильно интегрировано в конструкцию системы, в том числе но не ограничиваясь:
      Шифрование необходимое для хранения или передачи личных данных пользователей системы
            Шифрование необходимое для защиты самой системы от несанкционированного раскрытия или взлома 
Определение отдельных потребностей и контекстов для шифрования:
      Один-путь (т. е. ключ должен быть только у пользователя или получателя). Это может быть достигнуто с помощью криптографии с открытым ключом или других методов в которых шифрующая сторона (т. е., программное обеспечение) не нужно иметь доступ к закрытому ключу.
      Двухсторонний (т. е. шифрование может быть автоматически выполнено от имени пользователя но ключ должен быть доступен чтобы открытый текст мог быть автоматически восстановлен этим пользователем). Это требует хранения закрытого ключа в формате который может быть восстановлен только пользователем (или возможно операционной системой) таким образом который не может быть восстановлен другими.

Фаза: Архитектура и дизайн
Не разрабатывайте собственные криптографические алгоритмы. Они вероятно будут подвергаться атакам которые хорошо понятны криптографам. Методы обратного проектирования являются зрелыми. Если ваш алгоритм может быть скомпрометирован если злоумышленники узнают как он работает то он особенно слаб.

Фаза: Архитектура и дизайн
Выберите хорошо проверенный алгоритм который в настоящее время считается сильным экспертами в этой области, и выберите хорошо протестированные реализации.
Например, правительственные системы США требуют сертификации FIPS 140-2.
Как со всеми криптографическими механизмами, исходный код должен быть доступен для анализа.
Периодически убедитесь что Вы не используете устаревшую криптографию. Некоторые старые алгоритмы, когда-то думал, что потребуется миллиард лет вычислительного времени, теперь может быть нарушена в дни или часы. Это включает MD4, MD5, SHA1, DES, и другие алгоритмы которые когда-то считались сильными.

Фаза: Архитектура и дизайн
Разделите вашу систему чтобы иметь "безопасные" области где границы доверия могут быть однозначно нарисованы. Не допускайте выхода конфиденциальных данных за пределы границ доверия и всегда будьте осторожны при взаимодействии с отсеком за пределами безопасной зоны.

Фазы: Реализация; Архитектура и дизайн
При использовании одобренных в отрасли методов, вы должны использовать их правильно. Не режьте углы пропуская ресурсоемкие шаги (CWE-325). Эти шаги часто необходимы для предотвращения общих нападений.

Фаза: Реализация
Использовать соглашения об именовании и сильный Тип чтобы сделать его легче обнаружить когда конфиденциальные данные используется. При создании структур объектов, объекты, или другие сложные объекты как можно больше разделяют конфиденциальные и не чувствительные данные.
Это облегчает обнаружение мест в коде где используются незашифрованные данные.</solution>
	<reference>http://projects.webappsec.org/Insufficient-Transport-Layer-Protection</reference>
	<reference>http://cwe.mitre.org/data/definitions/311.html</reference>
</vuln_item_wasc_4>

<vuln_items>wasc_5</vuln_items>
<vuln_item_wasc_5>
	<alert>Удаленное Включение Файлов</alert>
	<desc>Удаленный файл включает (RFI) является метод атаки используемый для использования "динамического файла включают" механизмы в веб-приложениях. Когда веб-приложений используется для ввода данных (адрес, значение параметра и т. д.) и передать их в файл включают команды, веб-приложение может быть обманным путем включения удаленных файлов с вредоносным кодом.

Почти все платформы веб-приложений поддерживают включение файлов. Включение файлов в основном используется для упаковки общего кода в отдельные файлы на которые позже ссылаются основные модули приложений. Когда веб-приложение ссылается на включаемый файл код в этом файле может выполняться неявно или явно путем вызова определенных процедур. Если выбор модуля для загрузки основан на элементах из HTTP-запроса, веб-приложение может быть уязвимо для RFI.
Злоумышленник может использовать RFI для:
    * Запуск вредоносного кода на сервере: любой код в включенных вредоносных файлах будет запущен сервером. Если файл include не выполняется с помощью какой-либо оболочки, код в include файлах выполняется в контексте пользователя сервера. Это может привести к полной компрометации системы.
    * Выполнение вредоносного кода на клиентах: вредоносный код злоумышленника может управлять содержимым ответа отправленного клиенту. The attacker can embed malicious code in the response that will be run by the client (for example, JavaScript to steal the client session cookies).

PHP is particularly vulnerable to RFI attacks due to the extensive use of "file includes" in PHP programming and due to default server configurations that increase susceptibility to an RFI attack.</desc>
	<solution>Этап: архитектура и дизайн
Когда набор допустимых объектов, таких как имена файлов или URL-адресов, ограничен или известен, создайте сопоставление из набора фиксированных входных значений (например, числовых идентификаторов) с фактическими именами файлов или URL-адресами и отклоните все остальные входные данные. 
Например, ID 1 можно сопоставить с «inbox.txt», а идентификатор 2 - с «profile.txt».  Такие функции, как ESAPI AccessReferenceMap, предоставляют эту возможность. 

Фазы: архитектура и дизайн; Операция
Запустите свой код в «тюрьме» или подобной среде песочницы, которая устанавливает строгие границы между процессом и операционной системой.  Это может эффективно ограничить, к каким файлам можно получить доступ в конкретном каталоге или какие команды могут выполняться вашим программным обеспечением. 
Примеры уровня ОС включают chroot jail Unix, AppArmor и SELinux.  В общем, управляемый код может обеспечить некоторую защиту.  Например, java.io.FilePermission в Java SecurityManager позволяет вам указывать ограничения на файловые операции. 
Это может быть невыполнимым решением, и оно только ограничивает влияние на операционную систему; остальная часть вашего приложения все еще может быть скомпрометирована. 
Будьте осторожны, чтобы избежать CWE-243 и других уязвимостей, связанных с тюрьмами. 
Для PHP интерпретатор предлагает ограничения, такие как открытый или безопасный режим, которые могут затруднить выход злоумышленника из приложения.  Также рассмотрите Suhosin, защищенное расширение PHP, которое включает в себя различные параметры, отключающие некоторые из наиболее опасных функций PHP. 

Этап: реализация
Предположим, что весь ввод злонамерен.  Используйте стратегию проверки входных данных «принять заведомо исправные», т. е. Используйте разрешенный список допустимых входных данных, которые строго соответствуют спецификациям.  Отклоняйте любой ввод, который не строго соответствует спецификациям, или преобразуйте его во что-то, что соответствует.  Не полагайтесь исключительно на поиск вредоносных или искаженных входных данных (т. е. Не полагайтесь на список запрещенных).  Однако списки запрета могут быть полезны для обнаружения потенциальных атак или определения того, какие входные данные настолько искажены, что их следует сразу отклонить. 
При выполнении проверки ввода учитывайте все потенциально важные свойства, включая длину, тип ввода, полный диапазон допустимых значений, отсутствующие или дополнительные вводы, синтаксис, согласованность между связанными полями и соответствие бизнес-правилам.  В качестве примера логики бизнес-правила «лодка» может быть синтаксически допустимой, потому что она содержит только буквенно-цифровые символы, но недействительна, если вы ожидаете такие цвета, как «красный» или «синий». 
Для имен файлов используйте строгие списки разрешений, которые ограничивают используемый набор символов.  Если возможно, разрешите только один "." в имени файла, чтобы избежать таких слабых мест, как CWE-23, и исключить разделители каталогов, такие как «/», чтобы избежать CWE-36.  Используйте разрешенный список допустимых расширений файлов, который поможет избежать CWE-434. 

Фазы: архитектура и дизайн; Операция
По возможности храните файлы библиотеки, включаемые файлы и служебные файлы вне корня веб-документа.  В противном случае сохраните их в отдельном каталоге и используйте возможности управления доступом веб-сервера, чтобы злоумышленники не запрашивали их напрямую.  Одна из распространенных практик - определять фиксированную константу в каждой вызывающей программе, а затем проверять наличие константы в библиотеке / включаемом файле; если константа не существует, значит, файл был запрошен напрямую, и он может немедленно выйти. 
Это значительно снижает вероятность того, что злоумышленник сможет обойти любые механизмы защиты, которые есть в базовой программе, но не во включаемых файлах.  Это также уменьшит вашу поверхность атаки. 

Фазы: архитектура и дизайн; Реализация
Поймите все потенциальные области, в которых ненадежные входные данные могут попасть в ваше программное обеспечение: параметры или аргументы, файлы cookie, все, что считывается из сети, переменные среды, обратный поиск DNS, результаты запросов, заголовки запросов, компоненты URL, электронная почта, файлы, базы данных и любые внешние системы, которые предоставляют данные приложению.  Помните, что такие входные данные могут быть получены косвенно через вызовы API. 
Многие проблемы с включением файлов возникают из-за того, что программист предполагал, что определенные входные данные нельзя изменить, особенно для файлов cookie и компонентов URL. </solution>
	<reference>http://projects.webappsec.org/Remote-File-Inclusion</reference>
	<reference>http://cwe.mitre.org/data/definitions/98.html</reference>
</vuln_item_wasc_5>

<vuln_items>wasc_6</vuln_items>
<vuln_item_wasc_6>
	<alert>Формат Строки </alert>
	<desc>Атаки на форматную строку изменяют поток приложения, используя функции библиотеки форматирования строк для доступа к другому пространству памяти.  Уязвимости возникают, когда данные, предоставленные пользователем, используются непосредственно в качестве входной строки форматирования для определенных функций C / C ++ (например, fprintf, printf, sprintf, setproctitle, syslog, ...). 

Если злоумышленник передает строку формата, состоящую из символов преобразования printf (например, «% f», «% p», «% n» и т. д.) в качестве значения параметра в веб-приложение, он может: 
    * Выполнить произвольный код на сервере
    * Считывать значения из стека
    * Причина ошибок сегментации / сбоев программного обеспечения 


Атаки с форматной строкой связаны с другими атаками в Классификации угроз: переполнение буфера и целочисленное переполнение.  Все три основаны на их способности манипулировать памятью или ее интерпретацией таким образом, чтобы способствовать достижению цели злоумышленника. </desc>
	<solution>Фаза: Требования
Выберите язык, на котором нет этого недостатка. 

Этап: реализация
Убедитесь, что все функции форматирования строки передаются статической строкой, которой не может управлять пользователь, и что правильное количество аргументов также всегда отправляется этой функции.  По возможности используйте функции, которые не поддерживают оператор% n в строках формата. 
Сборка: обратите внимание на предупреждения компиляторов и компоновщиков, так как они могут предупредить вас о неправильном использовании. 
</solution>
	<reference>http://projects.webappsec.org/Format-String</reference>
	<reference>http://cwe.mitre.org/data/definitions/134.html</reference>
</vuln_item_wasc_6>

<vuln_items>wasc_7</vuln_items>
<vuln_item_wasc_7>
	<alert>Переполнение буфера</alert>
	<desc>Переполнение буфера - это ошибка, которая возникает, когда в блок памяти или буфер записывается больше данных, чем выделено для хранения буфера.  Использование переполнения буфера позволяет злоумышленнику изменять части адресного пространства целевого процесса.  Эта способность может использоваться для ряда целей, в том числе для следующих:
     * Контроль выполнения процесса
     * Сбой процесса
     * Изменить внутренние переменные

Цель атакующего почти всегда - контролировать выполнение целевого процесса.  Это достигается путем идентификации указателя функции в памяти, которая может быть изменена прямо или косвенно с помощью переполнения.  Когда такой указатель используется программой, чтобы направить выполнение программы через прыжок или вызвать инструкцию, будет использоваться местоположение инструкции предоставленной злоумышленником, тем самым позволяя злоумышленнику контролировать процесс.

Во многих случаях, указатель функции изменяется чтобы ссылаться на место где злоумышленник разместил собранные машинные инструкции. Эти инструкции обычно называются shellcode, со ссылкой на то что злоумышленники часто хотят создать среду командной строки, или shell, в контексте запущенного процесса.

Переполнения буфера чаще всего связаны с программным обеспечением написанным на языках программирования C и C++ из-за их широкого использования и способности выполнять прямые манипуляции с памятью с общими программными конструкциями. It should be emphasized, however, that buffer overflows can exist in any programming environment where direct memory manipulation is allowed, whether through flaws in the compiler, runtime libraries, or features of the language itself.
</desc>
	<solution>Этап: Требования
Используйте язык который не допускает возникновения этой слабости или предоставляет конструкции которые делают эту слабость легче избежать.
For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer.
Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.

Этап: Архитектура и дизайн
Используйте проверенную библиотеку или платформу которая не позволяет этому недостатку возникать или предоставляет конструкции которые делают эту слабость легче избежать.
Examples include the Safe C String Library (SafeStr) by Messier and Viega, and the Strsafe.h library from Microsoft. These libraries provide safer versions of overflow-prone string-handling functions. This is not a complete solution, since many buffer overflows are not related to strings.

Этап: сборка и компиляция
Запустите или скомпилируйте свое программное обеспечение, используя функции или расширения, которые автоматически обеспечивают механизм защиты, уменьшающий или устраняющий переполнение буфера. 
Например, некоторые компиляторы и расширения предоставляют механизмы автоматического обнаружения переполнения буфера, встроенные в скомпилированный код.  Примеры включают флаг Microsoft Visual Studio / GS, флаг Fedora / Red Hat FORTIFY SOURCE GCC, StackGuard и ProPolice. 

Этап: реализация
При распределении памяти приложения и управлении ею следует придерживаться следующих правил:
       Дважды проверьте, что ваш буфер такой большой, как вы указали. 
      При использовании функций, которые принимают количество байтов для копирования, таких как strncpy (), имейте в виду, что если размер целевого буфера равен размеру исходного буфера, он не может завершать строку NULL. 
      Проверьте границы буфера, если вызываете эту функцию в цикле, и убедитесь, что вам не угрожает запись за пределы выделенного пространства. 
      При необходимости обрежьте все входные строки до разумной длины, прежде чем передавать их функциям копирования и конкатенации. 

Фаза: Операция
Используйте такую функцию, как рандомизация разметки адресного пространства (ASLR). 

Фаза: Операция

Используйте ЦП и операционную систему, которая предлагает защиту выполнения данных (NX) или ее эквивалент. 

Этап: реализация

Замените функции неограниченного копирования аналогичными функциями, которые поддерживают аргументы длины, например strcpy на strncpy.  Создайте их, если они недоступны. 
</solution>
	<reference>http://projects.webappsec.org/Buffer-Overflow</reference>
	<reference>http://cwe.mitre.org/data/definitions/119.html</reference>
</vuln_item_wasc_7>

<vuln_items>wasc_8</vuln_items>
<vuln_item_wasc_8>
	<alert>Межсайтовый скриптинг </alert>
	<desc>Межсайтовый скриптинг (XSS) - это метод атаки, который включает повторение кода, предоставленного злоумышленником, в экземпляр браузера пользователя.  Экземпляр браузера может быть стандартным клиентом веб-браузера или объектом браузера, встроенным в программный продукт, например браузер в WinAmp, программу чтения RSS или клиент электронной почты.  Сам код обычно написан на HTML / JavaScript, но может также распространяться на VBScript, ActiveX, Java, Flash или любую другую технологию, поддерживаемую браузером. 
Когда злоумышленник заставляет браузер пользователя выполнить свой код, этот код будет выполняться в контексте (или зоне) безопасности веб-сайта, на котором он размещен.  С этим уровнем привилегий код имеет возможность читать, изменять и передавать любые конфиденциальные данные, доступные браузеру.  У пользователя с межсайтовым скриптом может быть взломана его / ее учетная запись (кража файлов cookie), их браузер перенаправлен в другое место или, возможно, будет показан мошеннический контент, доставленный веб-сайтом, который он посещает.  Атаки с использованием межсайтовых сценариев по существу ставят под угрозу доверительные отношения между пользователем и веб-сайтом.  Приложения, использующие экземпляры объектов браузера, которые загружают контент из файловой системы, могут выполнять код в зоне локального компьютера, что позволяет компрометировать систему. 

Существует три типа атак межсайтового скриптинга: непостоянные, постоянные и основанные на DOM. 
Непостоянные атаки и атаки на основе DOM требуют, чтобы пользователь либо посетил специально созданную ссылку с вредоносным кодом, либо посетил вредоносную веб-страницу, содержащую веб-форму, которая при размещении на уязвимом сайте инициирует атаку.  Использование вредоносной формы часто происходит, когда уязвимый ресурс принимает только запросы HTTP POST.  В таком случае форма может быть отправлена автоматически без ведома жертвы (например, с помощью JavaScript).  При нажатии на вредоносную ссылку или отправке вредоносной формы полезная нагрузка XSS будет отражена эхом, будет интерпретирована браузером пользователя и выполнена.  Другой способ отправки почти произвольных запросов (GET и POST) - использование встроенного клиента, такого как Adobe Flash. 
Постоянные атаки происходят, когда вредоносный код отправляется на веб-сайт, где он хранится в течение определенного периода времени.  Примеры излюбленных целей злоумышленника часто включают сообщения на досках объявлений, сообщения веб-почты и программное обеспечение для веб-чата.  Ничего не подозревающий пользователь не обязан взаимодействовать с каким-либо дополнительным сайтом / ссылкой (например, сайтом злоумышленника или вредоносной ссылкой, отправленной по электронной почте), просто просмотрите веб-страницу, содержащую код. </desc>
	<solution>Этап: Архитектура и дизайн
Используйте проверенную библиотеку или платформу которая не позволяет этому недостатку возникать или предоставляет конструкции которые делают эту слабость легче избежать.
Примеры библиотек и фреймворков, которые упрощают создание правильно закодированного вывода, включают библиотеку Microsoft Anti-XSS, модуль кодирования OWASP ESAPI и Apache Wicket. 

Этапы: реализация; Архитектура и дизайн
Поймите контекст, в котором будут использоваться ваши данные, и ожидаемую кодировку.  Это особенно важно при передаче данных между различными компонентами или при генерации выходных данных, которые могут содержать несколько кодировок одновременно, например, веб-страницы или составные почтовые сообщения.  Изучите все ожидаемые протоколы связи и представления данных, чтобы определить необходимые стратегии кодирования. 
Для любых данных, которые будут выводиться на другую веб-страницу, особенно для любых данных, полученных от внешних входов, используйте соответствующую кодировку для всех не буквенно-цифровых символов. 
Обратитесь к шпаргалке по предотвращению XSS для получения дополнительных сведений о необходимых типах кодирования и экранирования. 

Этап: архитектура и дизайн
Для любых проверок безопасности, которые выполняются на стороне клиента, убедитесь, что эти проверки дублируются на стороне сервера, чтобы избежать CWE-602.  Злоумышленники могут обойти проверки на стороне клиента, изменив значения после того, как проверки были выполнены, или изменив клиента, чтобы полностью удалить проверки на стороне клиента.  Затем эти измененные значения будут отправлены на сервер. 

Если возможно, используйте структурированные механизмы, которые автоматически обеспечивают разделение данных и кода.  Эти механизмы могут обеспечивать соответствующее цитирование, кодирование и проверку автоматически, вместо того, чтобы полагаться на разработчика, предоставляющего эту возможность в каждой точке, где генерируются выходные данные. 

Этап: реализация
Для каждой создаваемой веб-страницы используйте и укажите кодировку символов, такую как ISO-8859-1 или UTF-8.  Если кодировка не указана, веб-браузер может выбрать другую кодировку, угадав, какая кодировка фактически используется веб-страницей.  Это может привести к тому, что веб-браузер будет рассматривать определенные последовательности как особые, открывая клиента для тонких XSS-атак.  Смотри CWE-116 для дополнительных мер, связанных с кодированием / экранированием. 

Чтобы предотвратить атаки XSS на файл cookie сеанса пользователя, установите для файла cookie сеанса значение HttpOnly.  В браузерах, поддерживающих функцию HttpOnly (например, в более поздних версиях Internet Explorer и Firefox), этот атрибут может предотвратить доступ к cookie сеанса пользователя для вредоносных клиентских скриптов, использующих document.cookie.  Это не полное решение, поскольку HttpOnly поддерживается не всеми браузерами.  Что еще более важно, XMLHTTPRequest и другие мощные браузерные технологии предоставляют доступ для чтения к заголовкам HTTP, включая заголовок Set-Cookie, в котором установлен флаг HttpOnly. 

Предположим, что весь ввод злонамерен.  Используйте стратегию проверки входных данных «принять заведомо исправные», т. е. Используйте разрешенный список допустимых входных данных, которые строго соответствуют спецификациям.  Отклоняйте любой ввод, который не строго соответствует спецификациям, или преобразуйте его во что-то, что соответствует.  Не полагайтесь исключительно на поиск вредоносных или искаженных входных данных (т. е. Не полагайтесь на список запрещенных).  Однако списки запрета могут быть полезны для обнаружения потенциальных атак или определения того, какие входные данные настолько искажены, что их следует сразу отклонить. 

При выполнении проверки ввода учитывайте все потенциально важные свойства, включая длину, тип ввода, полный диапазон допустимых значений, отсутствующие или дополнительные вводы, синтаксис, согласованность между связанными полями и соответствие бизнес-правилам.  В качестве примера логики бизнес-правила «лодка» может быть синтаксически допустимой, потому что она содержит только буквенно-цифровые символы, но недействительна, если вы ожидаете такие цвета, как «красный» или «синий». 

Убедитесь, что вы выполняете проверку ввода на четко определенных интерфейсах в приложении.  Это поможет защитить приложение, даже если компонент будет повторно использован или перемещен в другое место. 
	</solution>
	<reference>http://projects.webappsec.org/Cross-Site-Scripting</reference>
	<reference>http://cwe.mitre.org/data/definitions/79.html</reference>
</vuln_item_wasc_8>

<vuln_items>wasc_9</vuln_items>
<vuln_item_wasc_9>
	<alert>Подделка межсайтовых запросов </alert>
	<desc>Подделка межсайтового запроса - это атака, которая включает в себя принуждение жертвы к отправке HTTP-запроса в целевой пункт назначения без ее ведома или намерения, чтобы выполнить действие в качестве жертвы.  Основная причина - функциональность приложения, использующая предсказуемые действия URL / формы повторяющимся образом.  Суть атаки заключается в том, что CSRF использует доверие, которое веб-сайт имеет к пользователю.  Напротив, межсайтовый скриптинг (XSS) использует доверие пользователя к веб-сайту.  Как и XSS, CSRF-атаки не обязательно являются межсайтовыми, но могут быть.  Подделка межсайтовых запросов также известна как CSRF, XSRF, атака в один клик, сессионная атака, сбитый с толку помощник и морской серфинг. 

CSRF-атаки эффективны в ряде ситуаций, в том числе:
     * У жертвы активный сеанс на целевом сайте. 
    * Жертва аутентифицируется через HTTP-аутентификацию на целевом сайте. 
    * Жертва находится в той же локальной сети, что и целевой сайт. 

CSRF в основном использовался для выполнения действия против целевого сайта с использованием привилегий жертвы, но недавно были обнаружены методы раскрытия информации путем получения доступа к ответу.  Риск раскрытия информации резко возрастает, когда целевой сайт уязвим для XSS, потому что XSS может использоваться в качестве платформы для CSRF, позволяя атаке действовать в рамках политики одного и того же происхождения. </desc>
	<solution>Этап: Архитектура и дизайн
Используйте проверенную библиотеку или платформу которая не позволяет этому недостатку возникать или предоставляет конструкции которые делают эту слабость легче избежать.
Например, используйте пакеты анти-CSRF, такие как OWASP CSRFGuard. 

Этап: реализация
Убедитесь, что в вашем приложении нет проблем с межсайтовыми сценариями, потому что большинство средств защиты CSRF можно обойти с помощью сценария, управляемого злоумышленником. 

Этап: архитектура и дизайн
Создайте уникальный одноразовый номер для каждой формы, поместите одноразовый номер в форму и проверьте одноразовый номер после получения формы.  Убедитесь, что одноразовый номер непредсказуем (CWE-330). 
Обратите внимание, что это можно обойти с помощью XSS. 

Определите особо опасные операции.  Когда пользователь выполняет опасную операцию, отправьте отдельный запрос подтверждения, чтобы убедиться, что пользователь намеревался выполнить эту операцию. 
Обратите внимание, что это можно обойти с помощью XSS. 

Используйте элемент управления ESAPI Session Management. 
Этот элемент управления включает компонент для CSRF. 

Не используйте метод GET для любого запроса, который вызывает изменение состояния. 

Этап: реализация
Проверьте заголовок HTTP Referer, чтобы узнать, исходит ли запрос от ожидаемой страницы.  Это может нарушить законную функциональность, поскольку пользователи или прокси-серверы могли отключить отправку Referer по соображениям конфиденциальности. </solution>
	<reference>http://projects.webappsec.org/Cross-Site-Request-Forgery</reference>
	<reference>http://cwe.mitre.org/data/definitions/352.html</reference>
</vuln_item_wasc_9>

<vuln_items>wasc_10</vuln_items>
<vuln_item_wasc_10>
	<alert>Отказ в обслуживании </alert>
	<desc>Отказ в обслуживании (DoS) - это метод атаки, цель которого - помешать веб-сайту обслуживать обычную активность пользователя.  DoS-атаки, которые обычно легко применяются на сетевом уровне, также возможны на уровне приложений.  Эти злонамеренные атаки могут быть успешными из-за нехватки критических ресурсов в системе, использования уязвимостей или злоупотребления функциональностью. 

Часто DoS-атаки будут пытаться использовать все доступные системные ресурсы веб-сайта, такие как: ЦП, память, дисковое пространство и т. д.  Когда какой-либо из этих критических ресурсов будет полностью использован, веб-сайт обычно будет недоступен. 

Поскольку современные среды веб-приложений включают в себя веб-сервер, сервер базы данных и сервер аутентификации, DoS на уровне приложения может быть нацелен на каждый из этих независимых компонентов.  В отличие от DoS на сетевом уровне, где требуется большое количество попыток подключения, DoS на уровне приложений представляет собой гораздо более простую задачу. </desc>
	<solution>Этап: архитектура и дизайн

Разработайте механизмы дросселирования в архитектуре системы.  Лучшая защита - это ограничить количество ресурсов, которые неавторизованный пользователь может использовать.  Надежная модель аутентификации и контроля доступа в первую очередь поможет предотвратить подобные атаки.  Приложение для входа в систему должно быть максимально защищено от DoS-атак.  Ограничение доступа к базе данных, возможно, путем кэширования наборов результатов, может помочь минимизировать затрачиваемые ресурсы.  Чтобы еще больше ограничить вероятность DoS-атаки, рассмотрите возможность отслеживания скорости запросов, полученных от пользователей, и блокировки запросов, которые превышают определенный порог скорости. 

Смягчение атак с истощением ресурсов требует, чтобы целевая система:
       распознает атаку и отказывает этому пользователю в дальнейшем доступе в течение определенного периода времени, или
       равномерно регулирует все запросы, чтобы усложнить потребление ресурсов быстрее, чем их можно будет снова освободить.  

Первое из этих решений само по себе является проблемой, поскольку может позволить злоумышленникам предотвратить использование системы конкретным действующим пользователем.  Если злоумышленник выдает себя за действительного пользователя, он может предотвратить доступ пользователя к рассматриваемому серверу. 

Второе решение просто сложно внедрить эффективно - и даже при правильном выполнении оно не дает полного решения.  Это просто заставляет атаку требовать больше ресурсов со стороны злоумышленника. 

Убедитесь, что протоколы имеют определенные ограничения масштаба. 

Этап: реализация
Убедитесь, что все сбои в распределении ресурсов переводят систему в безопасное состояние. </solution>
	<reference>http://projects.webappsec.org/Denial-of-Service</reference>
	<reference>http://cwe.mitre.org/data/definitions/400.html</reference>
</vuln_item_wasc_10>

<vuln_items>wasc_11a</vuln_items>
<vuln_item_wasc_11a>
	<alert>Грубая форсировка учетных данных для входа </alert>
	<desc>Атака полным перебором - это метод определения неизвестного значения с помощью автоматизированного процесса для проверки большого количества возможных значений.  Атака использует тот факт, что энтропия значений меньше, чем предполагалось.  Например, хотя 8-значный буквенно-цифровой пароль может иметь 2,8 триллиона возможных значений, многие люди будут выбирать свои пароли из гораздо меньшего подмножества, состоящего из общеупотребительных слов и терминов. 

Наиболее распространенный тип атаки методом перебора в веб-приложениях - это атака на учетные данные для входа.  Поскольку пользователям необходимо запоминать пароли, они часто выбирают простые для запоминания слова или фразы в качестве паролей, что делает полезными атаки методом перебора с использованием словаря.  Такую атаку с попыткой входа в систему с использованием большого списка слов и фраз в качестве потенциальных паролей часто называют «атакой по списку слов» или «атакой по словарю».  Испытываемые пароли могут также включать вариации слов, общих для паролей, например, сгенерированные заменой «o» на «0» и «i» на «1», а также личную информацию, включая имена членов семьи, даты рождения и номера телефонов. 
	</desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/Brute-Force</reference>
	<reference>TBA</reference>
</vuln_item_wasc_11a>

<vuln_items>wasc_11b</vuln_items>
<vuln_item_wasc_11b>
	<alert>Идентификаторы сеанса перебора </alert>
	<desc>Атака полным перебором - это метод определения неизвестного значения с помощью автоматизированного процесса для проверки большого количества возможных значений.  Атака использует тот факт, что энтропия значений меньше, чем предполагалось.  Например, хотя 8-значный буквенно-цифровой пароль может иметь 2,8 триллиона возможных значений, многие люди будут выбирать свои пароли из гораздо меньшего подмножества, состоящего из общеупотребительных слов и терминов. 

Поскольку HTTP является протоколом без сохранения состояния, для поддержания состояния веб-приложениям необходимо гарантировать, что идентификатор сеанса отправляется браузером с каждым запросом.  Идентификатор сеанса обычно хранится в файле cookie HTTP или URL-адресе.  Используя атаку методом грубой силы, злоумышленник может угадать идентификатор сеанса другого пользователя.  Это может привести к тому, что злоумышленник выдаст себя за пользователя, получит личную информацию и выполнит действия от имени пользователя. 
	</desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/Brute-Force</reference>
	<reference>TBA</reference>
</vuln_item_wasc_11b>

<vuln_items>wasc_11c</vuln_items>
<vuln_item_wasc_11c>
	<alert>Грубая форсировка каталогов и файлов </alert>
	<desc>Атака полным перебором - это метод определения неизвестного значения с помощью автоматизированного процесса для проверки большого количества возможных значений.  Атака использует тот факт, что энтропия значений меньше, чем предполагалось.  Например, хотя 8-значный буквенно-цифровой пароль может иметь 2,8 триллиона возможных значений, многие люди будут выбирать свои пароли из гораздо меньшего подмножества, состоящего из общеупотребительных слов и терминов. 

Когда файлы находятся в каталогах, которые обслуживаются веб-сервером, но нигде не связаны, для доступа к этим файлам необходимо знать их имя.  В некоторых случаях эти файлы были оставлены по ошибке: например, файл резервной копии, автоматически созданный при редактировании файла, или остатки от более старой версии веб-приложения.  В других случаях файлы намеренно не связываются как механизм «защиты от неизвестности», позволяющий получить к ним доступ только людям, знающим имена файлов. 

Атака методом грубой силы пытается найти несвязанный файл, пытаясь получить доступ к большому количеству файлов.  Список возможных имен файлов может быть взят из списка известных потенциальных файлов или на основе вариантов видимых файлов на веб-сайте.  Более подробную информацию о каталогах и файлах методом перебора можно найти в соответствующей уязвимости и предсказуемом расположении ресурсов. 
	</desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/Brute-Force</reference>
	<reference>TBA</reference>
</vuln_item_wasc_11c>

<vuln_items>wasc_11d</vuln_items>
<vuln_item_wasc_11d>
	<alert>Грубое принуждение информации о кредитной карте </alert>
	<desc>Атака полным перебором - это метод определения неизвестного значения с помощью автоматизированного процесса для проверки большого количества возможных значений.  Атака использует тот факт, что энтропия значений меньше, чем предполагалось.  Например, хотя 8-значный буквенно-цифровой пароль может иметь 2,8 триллиона возможных значений, многие люди будут выбирать свои пароли из гораздо меньшего подмножества, состоящего из общеупотребительных слов и терминов. 

Для покупок в Интернете с использованием украденных кредитных карт обычно требуется информация в дополнение к номеру кредитной карты, чаще всего это CVV / SCS и / или срок действия.  У мошенника может быть номер украденной кредитной карты без дополнительной информации.  Например, CVV / CSC не отпечатывается на карте и не хранится на магнитной полосе, поэтому он не может быть получен механическими или магнитными устройствами считывания кредитных карт. 

Чтобы заполнить недостающую информацию, хакер может угадать недостающую информацию, используя технику грубой силы, перебирая все возможные значения. 
    * Для угадывания CVV / CSC требуется всего 1000 или 10000 попыток, так как номер состоит всего из 3 или 4 цифр, в зависимости от типа карты. 
    * Для угадывания срока годности требуется всего несколько десятков попыток. 
	</desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/Brute-Force</reference>
	<reference>TBA</reference>
</vuln_item_wasc_11d>

<vuln_items>wasc_12</vuln_items>
<vuln_item_wasc_12>
	<alert>Подмена контента </alert>
	<desc>Подмена контента - это метод атаки, который позволяет злоумышленнику внедрить вредоносную полезную нагрузку, которая впоследствии будет искажена как законный контент веб-приложения. 
 
Подмена только текстового контента
Обычный подход к динамическому построению страниц включает передачу тела или его частей на страницу через значение строки запроса.  Этот подход распространен на страницах с ошибками или на сайтах, содержащих статьи или новости.  Содержимое, указанное в этом параметре, позже отражается на странице, чтобы предоставить содержимое для страницы. 
 
Подмена отраженного содержимого разметки
Некоторые веб-страницы обслуживаются с использованием динамически создаваемых источников содержимого HTML.  Например, исходное местоположение кадра  <frame src="http://foo.example/file.html"/>) может быть указано значением параметра URL.  (http://foo.example/page?frame_src=http://foo.example/file.html). Злоумышленник может заменить значение параметра frame_src на frame_src = http: //attacker.example/spoof.html.  В отличие от перенаправителей, когда результирующая веб-страница обслуживается, строка местоположения браузера явно остается под ожидаемым пользователем доменом (foo.example), но внешние данные (attacker.example) скрыты легитимным содержимым. 

Специально созданные ссылки могут быть отправлены пользователю по электронной почте, в мгновенных сообщениях, оставлены на досках объявлений или навязаны пользователям с помощью атаки межсайтового скриптинга.  Если злоумышленник заставляет пользователя посетить веб-страницу, обозначенную их вредоносным URL-адресом, пользователь будет полагать, что просматривает подлинный контент из одного места, а это не так.  Пользователи будут неявно доверять поддельному контенту, поскольку в строке местоположения браузера отображается http: //foo.example, тогда как на самом деле базовый HTML-фрейм ссылается на http: //attacker.example. 

Эта атака использует доверительные отношения, установленные между пользователем и веб-сайтом.  Этот метод использовался для создания поддельных веб-страниц, включая формы входа, искажения, ложные пресс-релизы и т. д.
	</desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/Content-Spoofing</reference>
	<reference>TBA</reference>
</vuln_item_wasc_12>

<vuln_items>wasc_13</vuln_items>
<vuln_item_wasc_13>
	<alert>Утечка информации </alert>
	<desc>Утечка информации - это слабое место приложения, при котором приложение раскрывает конфиденциальные данные, такие как технические детали веб-приложения, среды или пользовательские данные.  Конфиденциальные данные могут быть использованы злоумышленником для эксплуатации целевого веб-приложения, его хостинговой сети или пользователей.  Поэтому утечку конфиденциальных данных следует по возможности ограничивать или предотвращать.  Утечка информации, в ее наиболее распространенной форме, является результатом одного или нескольких из следующих условий: неспособность вычистить комментарии HTML / Script, содержащие конфиденциальную информацию, неправильные конфигурации приложения или сервера или различия в ответах страниц для допустимых и недействительных данных. . 

Если не очистить комментарии HTML / Script перед отправкой в производственную среду, это может привести к утечке конфиденциальной, контекстной информации, такой как структура каталогов сервера, структура запросов SQL и внутренняя сетевая информация.  Часто разработчик оставляет комментарии в коде HTML и / или сценария, чтобы облегчить процесс отладки или интеграции на этапе подготовки к производству.  Хотя разрешить разработчикам включать встроенные комментарии в разрабатываемый ими контент нет никакого вреда, все эти комментарии следует удалить до публичного выпуска контента. 

Номера версий программного обеспечения и подробные сообщения об ошибках (например, номера версий ASP.NET) являются примерами неправильной конфигурации сервера.  Эта информация полезна для злоумышленника, поскольку предоставляет подробные сведения о структуре, языках или встроенных функциях, используемых веб-приложением.  Большинство конфигураций серверов по умолчанию предоставляют номера версий программного обеспечения и подробные сообщения об ошибках для целей отладки и устранения неполадок.  Можно внести изменения в конфигурацию, чтобы отключить эти функции, предотвращая отображение этой информации. 

Страницы, которые предоставляют разные ответы в зависимости от достоверности данных, также могут привести к утечке информации; особенно когда данные, которые считаются конфиденциальными, раскрываются в результате разработки веб-приложения.  Примеры конфиденциальных данных включают (но не ограничиваются ими): номера учетных записей, идентификаторы пользователей (номер водительской лицензии, номер паспорта, номера социального страхования и т. Д.) И информацию о пользователях (пароли, сеансы, адреса).  Утечка информации в этом контексте связана с раскрытием ключевых пользовательских данных, считающихся конфиденциальными или секретными, которые не должны быть открыты для всеобщего обозрения даже пользователю.  Номера кредитных карт и другая строго регулируемая информация являются яркими примерами пользовательских данных, которые необходимо дополнительно защитить от раскрытия или утечки даже при наличии надлежащего шифрования и контроля доступа. </desc>
	<solution>Разделите свою систему, чтобы иметь «безопасные» области, где можно однозначно провести границы доверия.  Не допускайте выхода конфиденциальных данных за пределы границ доверия и всегда будьте осторожны при взаимодействии с отсеком за пределами безопасной зоны.</solution>
	<reference>http://projects.webappsec.org/Information-Leakage</reference>
	<reference>http://cwe.mitre.org/data/definitions/200.html</reference>
</vuln_item_wasc_13>

<vuln_items>wasc_14</vuln_items>
<vuln_item_wasc_14>
	<alert>Неверная конфигурация сервера </alert>
	<desc>Атаки неверной конфигурации сервера используют слабые места конфигурации, обнаруженные на веб-серверах и серверах приложений.  Многие серверы поставляются с ненужными файлами по умолчанию и образцами, включая приложения, файлы конфигурации, сценарии и веб-страницы.  У них также могут быть включены ненужные службы, такие как функции управления контентом и удаленного администрирования.  Могут быть включены отладочные функции или административные функции могут быть доступны анонимным пользователям.  Эти функции могут предоставить хакеру возможность обойти методы аутентификации и получить доступ к конфиденциальной информации, возможно, с повышенными привилегиями. 

Серверы могут включать в себя общеизвестные учетные записи и пароли по умолчанию.  Неспособность полностью заблокировать или укрепить сервер может привести к неправильной настройке прав доступа к файлам и каталогам.  Неверно настроенные сертификаты SSL и параметры шифрования, использование сертификатов по умолчанию и неправильная реализация аутентификации с внешними системами могут поставить под угрозу конфиденциальность информации. 

Подробные и информативные сообщения об ошибках могут привести к утечке данных, а раскрытая информация может быть использована для формулирования следующего уровня атаки.  Неправильная конфигурация серверного программного обеспечения может допускать атаки индексации каталогов и обхода пути. </desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/Server-Misconfiguration</reference>
	<reference/>
</vuln_item_wasc_14>

<vuln_items>wasc_15</vuln_items>
<vuln_item_wasc_15>
	<alert>Неверная конфигурация приложения </alert>
	<desc>Атаки из-за неправильной конфигурации приложений используют недостатки конфигурации, обнаруженные в веб-приложениях.  Многие приложения поставляются с ненужными и небезопасными функциями, такими как функции отладки и контроля качества, включенные по умолчанию.  Эти функции могут предоставить хакеру возможность обойти методы аутентификации и получить доступ к конфиденциальной информации, возможно, с повышенными привилегиями. 

Аналогичным образом, установки по умолчанию могут включать хорошо известные имена пользователей и пароли, жестко запрограммированные учетные записи бэкдора, специальные механизмы доступа и неправильные разрешения, установленные для файлов, доступных через веб-серверы.  Образцы по умолчанию могут быть доступны в производственных средах.  Файлы конфигурации на основе приложений, которые не заблокированы должным образом, могут отображать четкие текстовые строки подключения к базе данных, а параметры по умолчанию в файлах конфигурации могут быть заданы не с учетом требований безопасности.  Все эти неправильные конфигурации могут привести к несанкционированному доступу к конфиденциальной информации. </desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/Application-Misconfiguration</reference>
	<reference/>
</vuln_item_wasc_15>

<vuln_items>wasc_16</vuln_items>
<vuln_item_wasc_16>
	<alert>Индексирование каталогов </alert>
	<desc>Автоматический список / индексирование каталогов - это функция веб-сервера, которая перечисляет все файлы в запрошенном каталоге, если обычный базовый файл (index.html / home.html / default.htm / default.asp / default.aspx / index.php) нет.  Когда пользователь запрашивает главную страницу веб-сайта, он обычно вводит URL-адрес, например: http://www.example.com/directory1/ - используя имя домена и исключая конкретный файл.  Веб-сервер обрабатывает этот запрос и ищет в корневом каталоге документов имя файла по умолчанию и отправляет эту страницу клиенту.  Если эта страница отсутствует, веб-сервер динамически выдаст список каталогов и отправит результат клиенту.  По сути, это эквивалентно выполнению команды «ls» (Unix) или «dir» (Windows) в этом каталоге и отображению результатов в форме HTML.  С точки зрения атаки и противодействия важно понимать, что непреднамеренное перечисление каталогов может быть возможным из-за уязвимостей программного обеспечения (обсуждаемых в разделе примеров ниже) в сочетании с конкретным веб-запросом. </desc>
	<solution>Рекомендации включают ограничение доступа к важным каталогам или файлам путем принятия требования о необходимости знать как для документа, так и для корня сервера, а также отключение таких функций, как автоматические списки каталогов, которые могут раскрывать личные файлы и предоставлять информацию, которая может быть использована злоумышленником при формулировании или проведение нападения. </solution>
	<reference>http://projects.webappsec.org/Directory-Indexing</reference>
	<reference>http://cwe.mitre.org/data/definitions/548.html</reference>
</vuln_item_wasc_16>

<vuln_items>wasc_17</vuln_items>
<vuln_item_wasc_17>
	<alert>Неправильные разрешения файловой системы </alert>
	<desc>Неправильные разрешения файловой системы представляют собой угрозу конфиденциальности, целостности и доступности веб-приложения.  Проблема возникает, когда для файлов, папок и символических ссылок установлены неправильные разрешения файловой системы.  Если установлены неправильные разрешения, злоумышленник может получить доступ к файлам или каталогам с ограниченным доступом и изменить или удалить их содержимое.  Например, если учетная запись анонимного пользователя имеет разрешение на запись в файл, злоумышленник может изменить содержимое файла, влияя на веб-приложение нежелательными способами.  Злоумышленник также может использовать неправильные символические ссылки для повышения своих привилегий и / или доступа к неавторизованным файлам; например, символическая ссылка, указывающая на каталог за пределами корневого веб-каталога. </desc>
	<solution>Очень тщательно управляйте настройкой, управлением и обработкой разрешений.  Явно управляйте зонами доверия в программном обеспечении. </solution>
	<reference>http://projects.webappsec.org/Improper-Filesystem-Permissions</reference>
	<reference>http://cwe.mitre.org/data/definitions/280.html</reference>
</vuln_item_wasc_17>

<vuln_items>wasc_18</vuln_items>
<vuln_item_wasc_18>
	<alert>Учетные данные и прогнозирование сеанса </alert>
	<desc>Прогнозирование учетных данных / сеансов - это метод взлома или выдачи себя за пользователя веб-сайта.  Выведение или угадывание уникального значения, которое идентифицирует конкретный сеанс или пользователя, выполняет атаку.  Последствия, также известные как перехват сеанса, могут позволить злоумышленникам отправлять запросы к веб-сайтам с привилегиями скомпрометированного пользователя. 

Многие веб-сайты предназначены для аутентификации и отслеживания пользователя при первом установлении связи.  Для этого пользователи должны подтвердить свою личность на веб-сайте, обычно путем предоставления комбинации имени пользователя и пароля (учетных данных).  Вместо того, чтобы передавать эти конфиденциальные учетные данные туда и обратно с каждой транзакцией, веб-сайты будут генерировать уникальный «идентификатор сеанса», чтобы идентифицировать сеанс пользователя как аутентифицированный.  Последующее общение между пользователем и веб-сайтом помечается идентификатором сеанса как «доказательство» аутентифицированного сеанса.  Если злоумышленник может предсказать или угадать идентификатор сеанса другого пользователя, возможна мошенническая деятельность. </desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/Credential-and-Session-Prediction</reference>
	<reference/>
</vuln_item_wasc_18>

<vuln_items>wasc_19</vuln_items>
<vuln_item_wasc_19>
	<alert>SQL-инъекция</alert>
	<desc>SQL-инъекция - это метод атаки, используемый для использования приложений, которые создают операторы SQL из введенных пользователем данных.  В случае успеха злоумышленник может изменить логику операторов SQL, выполняемых для базы данных. 

Язык структурированных запросов (SQL) - это специализированный язык программирования для отправки запросов к базам данных.  Язык программирования SQL является одновременно стандартом ANSI и ISO, хотя многие продукты баз данных, поддерживающие SQL, делают это с помощью проприетарных расширений стандартного языка.  Приложения часто используют данные, предоставленные пользователем, для создания операторов SQL.  Если приложению не удается правильно построить операторы SQL, злоумышленник может изменить структуру оператора и выполнить незапланированные и потенциально враждебные команды.  Когда такие команды выполняются, они делают это в контексте пользователя, указанного приложением, выполняющим инструкцию.  Эта возможность позволяет злоумышленникам получить контроль над всеми ресурсами базы данных, доступными для этого пользователя, включая возможность выполнять команды в системе хостинга. </desc>
	<solution>Этап: Архитектура и дизайн
Используйте проверенную библиотеку или платформу которая не позволяет этому недостатку возникать или предоставляет конструкции которые делают эту слабость легче избежать.
Например, рассмотрите возможность использования уровней сохраняемости, таких как Hibernate или Enterprise Java Beans, которые при правильном использовании могут обеспечить значительную защиту от внедрения SQL. 

Если возможно, используйте структурированные механизмы, которые автоматически обеспечивают разделение данных и кода.  Эти механизмы могут обеспечивать соответствующее цитирование, кодирование и проверку автоматически, вместо того, чтобы полагаться на разработчика, предоставляющего эту возможность в каждой точке, где генерируются выходные данные. 

Обработка запросов SQL с помощью подготовленных операторов, параметризованных запросов или хранимых процедур.  Эти функции должны принимать параметры или переменные и поддерживать строгую типизацию.  Не создавайте и не выполняйте строки запроса в этих функциях динамически, используя «exec» или аналогичные функции, поскольку вы можете повторно ввести возможность внедрения SQL. 

Запустите свой код, используя самые низкие привилегии, необходимые для выполнения необходимых задач.  Если возможно, создайте изолированные учетные записи с ограниченными правами, которые используются только для одной задачи.  Таким образом, успешная атака не предоставит злоумышленнику немедленный доступ к остальному программному обеспечению или его среде.  Например, приложениям баз данных редко требуется запускать от имени администратора базы данных, особенно в повседневных операциях. 

В частности, следуйте принципу наименьших привилегий при создании учетных записей пользователей в базе данных SQL.  Пользователи базы данных должны иметь только минимальные привилегии, необходимые для использования их учетной записи.  Если требования системы указывают на то, что пользователь может читать и изменять свои собственные данные, ограничьте их права, чтобы они не могли читать / записывать чужие данные.  Используйте максимально строгие разрешения для всех объектов базы данных, например, только выполнение для хранимых процедур. 

Этап: реализация
Если вам необходимо использовать динамически генерируемые строки запроса или команды, несмотря на риск, правильно заключите аргументы в кавычки и избегайте любых специальных символов в этих аргументах.  Самый консервативный подход - экранировать или фильтровать все символы, которые не проходят чрезвычайно строгий список разрешений (например, все, что не является буквенно-цифровым или пробельным).  Если некоторые специальные символы все еще необходимы, например, пробел, заключите каждый аргумент в кавычки после этапа экранирования / фильтрации.  Будьте осторожны с инъекцией аргументов (CWE-88). 

Вместо создания собственной реализации такие функции могут быть доступны в базе данных или языке программирования.  Например, пакет Oracle DBMS ASSERT может проверять или обеспечивать соблюдение определенных свойств параметров, которые делают их менее уязвимыми для SQL-инъекций.  Для MySQL функция API mysql real escape string () доступна как в C, так и в PHP. 

Предположим, что весь ввод злонамерен.  Используйте стратегию проверки входных данных «принять заведомо исправные», т. е. Используйте разрешенный список допустимых входных данных, которые строго соответствуют спецификациям.  Отклоняйте любой ввод, который не строго соответствует спецификациям, или преобразуйте его во что-то, что соответствует.  Не полагайтесь исключительно на поиск вредоносных или искаженных входных данных (т. е. Не полагайтесь на список запрещенных).  Однако списки запрета могут быть полезны для обнаружения потенциальных атак или определения того, какие входные данные настолько искажены, что их следует сразу отклонить. 

При выполнении проверки ввода учитывайте все потенциально важные свойства, включая длину, тип ввода, полный диапазон допустимых значений, отсутствующие или дополнительные вводы, синтаксис, согласованность между связанными полями и соответствие бизнес-правилам.  В качестве примера логики бизнес-правила «лодка» может быть синтаксически допустимой, потому что она содержит только буквенно-цифровые символы, но недействительна, если вы ожидаете такие цвета, как «красный» или «синий». 

При построении строк запроса SQL используйте строгие списки разрешений, которые ограничивают набор символов на основе ожидаемого значения параметра в запросе.  Это косвенно ограничит масштаб атаки, но этот метод менее важен, чем правильное кодирование вывода и экранирование. 

Обратите внимание, что правильное кодирование вывода, экранирование и цитирование являются наиболее эффективным решением для предотвращения внедрения SQL, хотя проверка ввода может обеспечить некоторую глубинную защиту.  Это потому, что он эффективно ограничивает то, что будет отображаться на выходе.  Проверка ввода не всегда предотвращает внедрение SQL, особенно если вам необходимо поддерживать текстовые поля произвольной формы, которые могут содержать произвольные символы.  Например, имя «О'Рейли», скорее всего, пройдет этап проверки, поскольку это обычная фамилия на английском языке.  Однако его нельзя напрямую вставить в базу данных, потому что он содержит символ апострофа «'», который нужно было бы экранировать или обработать иным образом.  В этом случае удаление апострофа может снизить риск SQL-инъекции, но приведет к неправильному поведению, поскольку будет записано неправильное имя. 

По возможности, безопаснее всего полностью запретить метасимволы вместо их экранирования.  Это обеспечит некоторую глубокую защиту.  После ввода данных в базу данных более поздние процессы могут игнорировать экранирование метасимволов перед использованием, и вы можете не контролировать эти процессы. </solution>
	<reference>http://projects.webappsec.org/SQL-Injection</reference>
	<reference/>
</vuln_item_wasc_19>

<vuln_items>wasc_20</vuln_items>
<vuln_item_wasc_20>
	<alert>Неправильная обработка ввода </alert>
	<desc>Неправильная обработка ввода - одна из наиболее распространенных слабостей, выявленных сегодня во всех приложениях.  Плохо обрабатываемый ввод - основная причина критических уязвимостей, существующих в системах и приложениях. 
	
Как правило, термин «обработка ввода» используется для описания таких функций, как проверка, очистка, фильтрация, кодирование и / или декодирование входных данных.  Приложения получают входные данные из различных источников, включая пользователей, программные агенты (браузеры) и сетевые / периферийные устройства, и это лишь некоторые из них.  В случае веб-приложений ввод можно передавать в различных форматах (пары имя-значение, JSON, SOAP и т. Д.) И получать через строки запроса URL, данные POST, заголовки HTTP, файлы cookie и т. д.  Входные данные, не относящиеся к веб-приложению, могут быть получены через переменные приложения, переменные среды, реестр, файлы конфигурации и т. д.  Независимо от формата данных или источника / местоположения ввода, все вводимые данные следует считать ненадежными и потенциально вредоносными.  Приложения, обрабатывающие ненадежный ввод, могут стать уязвимыми для таких атак, как переполнение буфера, внедрение SQL, управление ОС, отказ в обслуживании и многие другие. 

Одним из ключевых аспектов обработки ввода является проверка того, что ввод удовлетворяет определенным критериям.  Для надлежащей проверки важно определить форму и тип данных, которые приемлемы и ожидаются приложением.  Для точного определения ограничений требуется определение ожидаемого формата и использования каждого экземпляра ненадежных входных данных.  

Проверка может включать проверки безопасности типов и правильного синтаксиса.  String input can be checked for length (min and max number of characters) and character set validation while numeric input types like integers and decimals can be validated against acceptable upper and lower bound of values. When combining input from multiple sources, validation should be performed during concatenation and not just against the individual data elements. This practice helps avoid situations where input validation may succeed when performed on individual data items but fails when done on a combined set from all the sources.</desc>
	<solution>Этап: архитектура и дизайн

Используйте структуру проверки ввода, такую как Struts или OWASP ESAPI Validation API. 

Поймите все потенциальные области, в которых ненадежные входные данные могут попасть в ваше программное обеспечение: параметры или аргументы, файлы cookie, все, что считывается из сети, переменные среды, обратный поиск DNS, результаты запросов, заголовки запросов, компоненты URL, электронная почта, файлы, базы данных и любые внешние системы, которые предоставляют данные приложению.  Помните, что такие входные данные могут быть получены косвенно через вызовы API. 

Для любых проверок безопасности, выполняемых на стороне клиента, убедитесь, что эти проверки дублируются на стороне сервера.  Злоумышленники могут обойти проверки на стороне клиента, изменив значения после того, как проверки были выполнены, или изменив клиента, чтобы полностью удалить проверки на стороне клиента.  Затем эти измененные значения будут отправлены на сервер. 

Несмотря на то, что проверки на стороне клиента обеспечивают минимальные преимущества в отношении безопасности на стороне сервера, они все же полезны.  Во-первых, они могут поддерживать обнаружение вторжений.  Если сервер получает ввод, который должен был быть отклонен клиентом, это может быть признаком атаки.  Во-вторых, проверка ошибок на стороне клиента может предоставить пользователю полезную обратную связь об ожиданиях правильного ввода.  В-третьих, может сократиться время обработки случайных ошибок ввода на стороне сервера, хотя обычно это небольшая экономия. 

Не полагайтесь исключительно на проверку списка запретов для обнаружения вредоносных входных данных или кодирования выходных данных.  Существует слишком много способов кодирования одного и того же символа, поэтому вы, вероятно, пропустите некоторые варианты. 

Если ваше приложение объединяет данные из нескольких источников, выполните проверку после объединения источников.  Отдельные элементы данных могут пройти этап проверки, но нарушить намеченные ограничения после того, как они были объединены. 

Предположим, что весь ввод злонамерен.  Используйте стратегию проверки входных данных «принять заведомо исправные», т. е. Используйте разрешенный список допустимых входных данных, которые строго соответствуют спецификациям.  Отклоняйте любой ввод, который не строго соответствует спецификациям, или преобразуйте его во что-то, что соответствует.  Не полагайтесь исключительно на поиск вредоносных или искаженных входных данных (т. е. Не полагайтесь на список запрещенных).  Однако списки запрета могут быть полезны для обнаружения потенциальных атак или определения того, какие входные данные настолько искажены, что их следует сразу отклонить. 

При выполнении проверки ввода учитывайте все потенциально важные свойства, включая длину, тип ввода, полный диапазон допустимых значений, отсутствующие или дополнительные вводы, синтаксис, согласованность между связанными полями и соответствие бизнес-правилам.  В качестве примера логики бизнес-правила «лодка» может быть синтаксически допустимой, потому что она содержит только буквенно-цифровые символы, но недействительна, если вы ожидаете такие цвета, как «красный» или «синий». 

Этап: реализация

Будьте особенно осторожны при проверке ввода, когда вы вызываете код, который пересекает языковые границы, например, с интерпретируемого языка на собственный код.  Это может создать неожиданное взаимодействие между языковыми границами.  Убедитесь, что вы не нарушаете никаких ожиданий от языка, с которым вы взаимодействуете.  Например, даже несмотря на то, что Java может быть невосприимчивой к переполнению буфера, предоставление большого аргумента при вызове собственного кода может вызвать переполнение. 

Непосредственно преобразуйте свой тип ввода в ожидаемый тип данных, например, используя функцию преобразования, которая переводит строку в число.  После преобразования в ожидаемый тип данных убедитесь, что входные значения попадают в ожидаемый диапазон допустимых значений и что сохраняется согласованность нескольких полей. 

Перед проверкой входные данные должны быть декодированы и канонизированы в текущее внутреннее представление приложения.  Убедитесь, что ваше приложение случайно не декодирует один и тот же ввод дважды.  Такие ошибки можно использовать для обхода схем разрешенных списков путем введения опасных входных данных после их проверки.  Используйте библиотеки, такие как элемент управления канонизацией OWASP ESAPI. 

Рассмотрите возможность повторной канонизации, пока ваш ввод больше не изменится.  Это позволит избежать двойного декодирования и подобных сценариев, но может непреднамеренно изменить входные данные, которым разрешено содержать правильно закодированный опасный контент. 

При обмене данными между компонентами убедитесь, что оба компонента используют одинаковую кодировку символов.  Убедитесь, что на каждом интерфейсе применяется правильная кодировка.  Явно установите кодировку, которую вы используете, когда протокол позволяет вам это сделать. </solution>
	<reference>http://projects.webappsec.org/Improper-Input-Handling</reference>
	<reference>http://cwe.mitre.org/data/definitions/89.html</reference>
</vuln_item_wasc_20>

<vuln_items>wasc_21</vuln_items>
<vuln_item_wasc_21>
	<alert>Недостаточная антиавтоматика </alert>
	<desc>Недостаточная защита от автоматизации возникает, когда веб-приложение позволяет злоумышленнику автоматизировать процесс, который изначально был разработан для выполнения только вручную, то есть веб-пользователем-человеком. 

Функциональные возможности веб-приложений, которые часто становятся целью атак автоматизации, могут включать:
    * Формы входа в приложение - злоумышленники могут автоматизировать запросы входа в систему методом грубой силы, пытаясь угадать учетные данные пользователя.
    * Формы регистрации услуг - злоумышленники могут автоматически создавать тысячи новых учетных записей.
    * Формы электронной почты - злоумышленники могут использовать формы электронной почты в качестве рассылки спама или для переполнения почтового ящика определенного пользователя.
    * Обслуживание учетной записи - злоумышленники могут выполнять массовые DoS-атаки против приложения, наводняя его многочисленными запросами на отключение или удаление учетных записей пользователей.
    * Формы информации об аккаунте - злоумышленники могут совершать массовые попытки сбора личной информации пользователя из веб-приложения.
    * Формы комментариев / формы отправки содержимого - их можно использовать для рассылки спама в блогах, веб-форумах и досках объявлений путем автоматической отправки содержимого, такого как спам или даже вредоносное ПО в Интернете.
    * Формы, привязанные к запросам базы данных SQL - они могут быть использованы для выполнения атаки отказа в обслуживании против приложения.  Атака осуществляется путем отправки множества тяжелых SQL-запросов за короткий период времени, что приводит к отказу от обслуживания реальных пользователей. 
    * Электронные магазины / электронная коммерция - приложения для электронных покупок и электронной коммерции, которые не привлекают покупателей только для людей, могут использоваться для покупки предпочтительных товаров в больших количествах, таких как билеты на спортивные мероприятия.  Позже они продаются скальперами по более высокой цене. 
    * Онлайн-опросы - опросы и другие типы систем онлайн-голосования могут быть автоматически подорваны в пользу определенного выбора. 
    * Отправка SMS-сообщений через Интернет - злоумышленники могут использовать системы отправки SMS-сообщений для рассылки спама пользователям мобильных телефонов. 
	</desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/Insufficient+Anti-automation</reference>
	<reference>http://cwe.mitre.org/data/definitions/116.html</reference>
</vuln_item_wasc_21>

<vuln_items>wasc_22</vuln_items>
<vuln_item_wasc_22>
	<alert>Неправильная обработка вывода </alert>
	<desc>Обработка вывода относится к тому, как приложение генерирует исходящие данные.   Если приложение неправильно обрабатывает выходные данные, выходные данные могут быть использованы, что приведет к уязвимостям и действиям, которые разработчик приложения не предполагал.   Во многих случаях эта непреднамеренная интерпретация классифицируется как одна или несколько форм критических уязвимостей приложений. 

Любое место, где данные покидают границу приложения, может подвергаться неправильной обработке вывода.   Границы приложения существуют там, где данные выходят из одного контекста и попадают в другой.   Это включает в себя передачу данных в другие приложения через веб-службы, сокеты, командную строку, переменные среды и т. д. ) или операционной системы.   Более подробную информацию о том, где может произойти неправильная обработка вывода, можно найти в разделе ниже, озаглавленном «Места вывода общих данных». 

Неправильная обработка вывода может принимать различные формы в приложении.   Эти формы можно разделить на следующие категории: ошибки протокола, ошибки приложения и ошибки, связанные с потребителями данных.   Ошибки протокола включают отсутствие или неправильную кодировку вывода или экранирование и вывод недопустимых данных.   К ошибкам приложений относятся логические ошибки, такие как вывод неверных данных или передача нефильтрованного вредоносного содержимого.   Если приложение не может должным образом отличить законный контент от незаконного или не обходит известные уязвимости потребителя данных, это может привести к злоупотреблениям со стороны потребителя данных из-за неправильной обработки выходных данных. 

Приложение, которое не предоставляет данные в правильном контексте, может позволить злоумышленнику злоупотребить потребителем данных.   Это может привести к определенным угрозам, указанным в классификации угроз WASC, включая подмену контента, межсайтовые сценарии, разделение HTTP-ответа, контрабанду HTTP-ответа, внедрение LDAP, команд ОС, обход маршрутизации, злоупотребление массивом мыла, перенаправитель URL-адресов, внедрение XML, XQuery. Внедрение, Внедрение XPath, Внедрение почтовых команд, Внедрение нулей и Внедрение SQL. 

Правильная обработка вывода предотвращает неожиданную или непреднамеренную интерпретацию данных потребителем.   Для достижения этой цели разработчики должны понимать модель данных приложения, то, как данные будут использоваться другими частями приложения и как они будут в конечном итоге представлены пользователю.   Методы обеспечения надлежащей обработки вывода включают, помимо прочего, фильтрацию и дезинфекцию данных (более подробную информацию о дезинфекции и фильтрации выходных данных можно найти в разделах с соответствующими названиями ниже).   Однако непоследовательное использование выбранных методов обработки выходных данных может фактически увеличить риск неправильной обработки выходных данных, если выходные данные игнорируются или не обрабатываются.   Для обеспечения «глубокой защиты» разработчики должны исходить из того, что все данные в приложении не являются надежными при выборе подходящей стратегии обработки вывода. 

Хотя правильная обработка вывода может принимать множество различных форм, приложение не может быть безопасным, если оно не защищает от непреднамеренной интерпретации потребителем данных.  Это основное требование необходимо для того, чтобы приложение могло безопасно обрабатывать операции вывода. </desc>
	<solution>Используйте проверенную библиотеку или фреймворк, которые не допускают появления этой уязвимости или предоставляют конструкции, которые упрощают ее устранение. 

Например, рассмотрите возможность использования элемента управления кодированием ESAPI или аналогичного инструмента, библиотеки или инфраструктуры.  Это поможет программисту кодировать выходные данные менее подверженным ошибкам. 

В качестве альтернативы используйте встроенные функции, но рассмотрите возможность использования оболочек на случай, если обнаружится, что в этих функциях есть уязвимости. 

Если возможно, используйте структурированные механизмы, которые автоматически обеспечивают разделение данных и кода.  Эти механизмы могут обеспечивать соответствующее цитирование, кодирование и проверку автоматически, вместо того, чтобы полагаться на разработчика, предоставляющего эту возможность в каждой точке, где генерируются выходные данные. 

Например, хранимые процедуры могут обеспечить соблюдение структуры запроса к базе данных и снизить вероятность внедрения SQL-кода. 

Поймите контекст, в котором будут использоваться ваши данные, и ожидаемую кодировку.  Это особенно важно при передаче данных между различными компонентами или при генерации выходных данных, которые могут содержать несколько кодировок одновременно, например, веб-страницы или составные почтовые сообщения.  Изучите все ожидаемые протоколы связи и представления данных, чтобы определить необходимые стратегии кодирования. 

В некоторых случаях проверка ввода может быть важной стратегией, когда кодирование вывода не является полным решением.  Например, вы можете предоставлять один и тот же вывод, который будет обрабатываться несколькими потребителями, использующими разные кодировки или представления.  В других случаях вам может потребоваться разрешить вводимые пользователем данные содержать управляющую информацию, такую как ограниченные теги HTML, поддерживающие форматирование в вики или доске объявлений.  Когда этот тип требований должен быть удовлетворен, используйте чрезвычайно строгий список разрешений, чтобы ограничить, какие управляющие последовательности могут использоваться.  Убедитесь, что полученная синтаксическая структура соответствует вашим ожиданиям.  Для оставшейся части ввода используйте обычные методы кодирования. 

Используйте проверку входных данных в качестве меры глубокой защиты, чтобы снизить вероятность ошибок кодирования выходных данных (см. CWE-20). 

При обмене данными между компонентами убедитесь, что оба компонента используют одинаковую кодировку символов.  Убедитесь, что на каждом интерфейсе применяется правильная кодировка.  Явно установите кодировку, которую вы используете, когда протокол позволяет вам это сделать. </solution>
	<reference>http://projects.webappsec.org/Improper-Output-Handling</reference>
	<reference/>
</vuln_item_wasc_22>

<vuln_items>wasc_23</vuln_items>
<vuln_item_wasc_23>
	<alert>XML-инъекция </alert>
	<desc>XML-инъекция - это метод атаки, используемый для манипулирования или компрометации логики XML-приложения или службы.  Внедрение непреднамеренного XML-содержимого и / или структур в XML-сообщение может изменить логику намерений приложения.  Кроме того, внедрение XML может вызвать вставку вредоносного содержимого в итоговое сообщение / документ. </desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/XML-Injection</reference>
	<reference/>
</vuln_item_wasc_23>

<vuln_items>wasc_24</vuln_items>
<vuln_item_wasc_24>
	<alert>Разделение HTTP-запроса </alert>
	<desc>Разделение HTTP-запросов - это атака, которая позволяет заставить браузер отправлять произвольные HTTP-запросы, вызывая XSS и отравляя кеш браузера.  Суть атаки заключается в способности злоумышленника, когда жертва (браузер) вынуждена загрузить вредоносную HTML-страницу злоумышленника, манипулировать одной из функций браузера для отправки 2 HTTP-запросов вместо одного HTTP-запроса.  На сегодняшний день используются два таких механизма: объект XmlHttpRequest (сокращенно XHR) и механизм дайджест-аутентификации HTTP.  Чтобы эта атака сработала, браузер должен использовать прямой HTTP-прокси (не все из них «поддерживают» эту атаку), либо атака должна быть проведена против хоста, расположенного на том же IP (с точки зрения браузера), что и злоумышленник. машина. </desc>
	<solution>Избегайте использования CRLF в качестве специальной последовательности. 

Соответственно фильтруйте или цитируйте последовательности CRLF во вводе, управляемом пользователем. </solution>
	<reference>http://projects.webappsec.org/HTTP-Request-Splitting</reference>
	<reference>http://cwe.mitre.org/data/definitions/93.html</reference>
</vuln_item_wasc_24>

<vuln_items>wasc_25</vuln_items>
<vuln_item_wasc_25>
	<alert>Разделение HTTP-ответа </alert>
	<desc>В атаке с разделением HTTP-ответа всегда участвуют 3 стороны (как минимум):
     * Веб-сервер с дырой в безопасности, позволяющей разделение HTTP-ответа.
     * Цель - объект, который взаимодействует с веб-сервером, возможно, от имени злоумышленника.  Typically this is a cache server forward/reverse proxy), or a browser (possibly with a browser cache).
    * Атакующий - инициирует атаку

Суть разделения HTTP-ответа заключается в способности злоумышленника отправить один HTTP-запрос, который заставляет веб-сервер формировать выходной поток, который затем интерпретируется целью как два HTTP-ответа вместо одного ответа в обычном случае.  Первый ответ может частично контролироваться злоумышленником, но это менее важно.  Существенно то, что злоумышленник полностью контролирует форму второго ответа от строки состояния HTTP до последнего байта тела ответа HTTP.  Как только это становится возможным, злоумышленник реализует атаку, отправляя два запроса через цель.  Первый вызывает два ответа от веб-сервера, а второй запрос обычно направляется к какому-то «невиновному» ресурсу на веб-сервере.  Однако второй запрос будет сопоставлен целью со вторым HTTP-ответом, который полностью контролируется злоумышленником.  Таким образом, злоумышленник обманом заставляет цель поверить в то, что конкретный ресурс на веб-сервере (обозначенный вторым запросом) является HTTP-ответом сервера (содержимое сервера), в то время как на самом деле это некоторые данные, которые подделываются злоумышленником через веб-сервер - это второй ответ. 

Атаки с разделением HTTP-ответа имеют место, когда серверный сценарий встраивает пользовательские данные в заголовки HTTP-ответа.  Обычно это происходит, когда сценарий встраивает данные пользователя в URL-адрес перенаправления ответа на перенаправление (код состояния HTTP 3xx) или когда сценарий встраивает данные пользователя в значение или имя файла cookie, когда ответ устанавливает файл cookie. </desc>
	<solution>Создавайте заголовки HTTP очень тщательно, избегая использования непроверенных входных данных. </solution>
	<reference>http://projects.webappsec.org/HTTP-Response-Splitting</reference>
	<reference>http://cwe.mitre.org/data/definitions/113.html</reference>
</vuln_item_wasc_25>

<vuln_items>wasc_26</vuln_items>
<vuln_item_wasc_26>
	<alert>HTTP Request Smuggling</alert>
	<desc>Контрабанда HTTP-запросов - это метод атаки, который злоупотребляет несоответствием в разборе HTTP-запросов, несовместимых с RFC, между двумя HTTP-устройствами (обычно интерфейсным прокси-сервером или межсетевым экраном с поддержкой HTTP и внутренним веб-сервером) для передачи запроса второму устройство «через» первое устройство.  Этот метод позволяет злоумышленнику отправить один набор запросов на второе устройство, в то время как первое устройство видит другой набор запросов.  В свою очередь, это облегчает несколько возможных атак, таких как частичное отравление кеша, обход защиты брандмауэра и XSS. </desc>
	<solution>Используйте веб-сервер, который использует строгую процедуру синтаксического анализа HTTP, например Apache (см. Справочную статью). 

Используйте только SSL-соединение. 

Завершайте клиентский сеанс после каждого запроса. 

Turn all pages to non-cacheable.</solution>
	<reference>http://projects.webappsec.org/HTTP-Request-Smuggling</reference>
	<reference>http://cwe.mitre.org/data/definitions/444.html</reference>
</vuln_item_wasc_26>

<vuln_items>wasc_27</vuln_items>
<vuln_item_wasc_27>
	<alert>Контрабанда HTTP-ответов </alert>
	<desc>Контрабанда HTTP-ответов - это метод «контрабанды» 2 HTTP-ответов от сервера к клиенту через промежуточное HTTP-устройство, которое ожидает (или разрешает) один ответ от сервера. 

Одно из применений этой техники - усовершенствовать базовую технику разделения HTTP-ответа, чтобы избежать мер по разделению HTTP-ответа.  В этом случае посредником является механизм разделения ответа HTTP между веб-сервером и прокси-сервером (или веб-браузером).  Другой вариант использования - подделка ответов, полученных браузером.  В этом случае вредоносный веб-сайт предоставляет браузеру страницу, которая интерпретируется браузером как происходящая из другого (целевого) домена.  Для этого можно использовать контрабанду HTTP-ответов, когда браузер использует прокси-сервер для доступа к обоим сайтам. 

Контрабанда HTTP-ответов использует методы, похожие на контрабанду HTTP-запросов, чтобы использовать несоответствия между тем, что анти-HTTP-механизм разделения ответа (или прокси-сервер) будет рассматривать как поток HTTP-ответа, и поток ответа, анализируемый прокси-сервером. (или браузер).  Таким образом, в то время как механизм разделения ответа HTTP может считать конкретный поток ответа безвредным (один HTTP-ответ), прокси / браузер может по-прежнему анализировать его как два HTTP-ответа и, следовательно, быть восприимчивым ко всем результатам исходного разделения HTTP-ответа. техники (в первом случае использования) или подвержены спуфингу страницы (во втором случае).  Например, некоторые механизмы разделения ответа HTTP, используемые некоторыми механизмами приложений, запрещают приложению вставлять в ответ заголовок, содержащий CR + LF.  Тем не менее, злоумышленник может заставить приложение вставить заголовок, содержащий CR, тем самым обойдя механизм защиты.  Некоторые прокси-серверы могут по-прежнему рассматривать CR (только) как разделитель заголовка (и ответа), и поэтому комбинация веб-сервера и прокси-сервера по-прежнему будет уязвима для атаки, которая может отравить кеш прокси. 
	</desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/HTTP-Response-Smuggling</reference>
	<reference/>
</vuln_item_wasc_27>

<vuln_items>wasc_28</vuln_items>
<vuln_item_wasc_28>
	<alert>Инъекция нулевого байта </alert>
	<desc>Инъекция нулевого байта - это активный метод эксплуатации, используемый для обхода фильтров проверки работоспособности в веб-инфраструктуре путем добавления символов нулевого байта в кодировке URL (например,% 00 или 0x00 в шестнадцатеричном формате) к пользовательским данным.  Этот процесс внедрения может изменить предполагаемую логику приложения и позволить злоумышленнику получить несанкционированный доступ к системным файлам. 

Большинство веб-приложений сегодня разрабатываются с использованием языков более высокого уровня, таких как PHP, ASP, Perl и Java.  Однако эти веб-приложения в какой-то момент требуют обработки высокоуровневого кода на системном уровне, и этот процесс обычно выполняется с помощью функций «C / C ++».  Разнообразный характер этих зависимых технологий привел к появлению класса атаки, называемого атакой «Null Byte Injection» или «Null Byte Poisoning».  В C / C ++ нулевой байт представляет точку завершения строки или символ-разделитель, что означает немедленную остановку обработки строки.  Байты, следующие за разделителем, игнорируются.  Если строка теряет свой нулевой символ, длина строки становится неизвестной до тех пор, пока указатель памяти не встретит следующий нулевой байт.  Это непреднамеренное разветвление может вызвать необычное поведение и внести уязвимости в систему или область приложения.  Аналогичным образом, несколько языков более высокого уровня обрабатывают «нулевой байт» как заполнитель для длины строки, поскольку он не имеет особого значения в их контексте.  Из-за этой разницы в интерпретации нулевые байты могут быть легко введены для управления поведением приложения. 

URL-адреса ограничены набором символов US-ASCII в диапазоне от 0x20 до 0x7E (шестнадцатеричный) или от 32 до 126 (десятичный).  Однако в вышеупомянутом диапазоне используются несколько недопустимых символов, поскольку они имеют особое значение в контексте протокола HTTP.  По этой причине была введена схема кодирования URL для включения специальных символов в URL с использованием расширенного представления символов ASCII.  В терминах «нулевого байта» это представлено как% 00 в шестнадцатеричном формате.  Атака с нулевым байтом начинается там, где веб-приложения взаимодействуют с активными подпрограммами «C» и внешними API из базовой ОС.  Таким образом, злоумышленник может манипулировать веб-ресурсами путем чтения или записи файлов в зависимости от прав пользователя приложения. </desc>
	<solution>Разработчики должны ожидать, что нулевые символы или нулевые байты будут введены / удалены / обработаны во входных векторах их программной системы.  Используйте соответствующую комбинацию черных списков и белых списков, чтобы гарантировать, что система обрабатывает только действительные, ожидаемые и соответствующие входные данные. 

Предположим, что весь ввод злонамерен.  Используйте стандартный механизм проверки ввода, чтобы проверить все вводимые данные на предмет длины, типа, синтаксиса и бизнес-правил, прежде чем принимать данные для отображения или сохранения.  Используйте стратегию проверки «принять заведомо исправный». 

Используйте и укажите строгую кодировку вывода (например, ISO 8859-1 или UTF 8). 

Не полагайтесь исключительно на проверку списка запретов для обнаружения вредоносных входных данных или кодирования выходных данных.  Существует слишком много вариантов кодирования символа; вы скорее всего пропустите некоторые варианты. 

Перед проверкой входные данные должны быть декодированы и канонизированы в текущее внутреннее представление приложения.  Убедитесь, что ваше приложение не декодирует один и тот же ввод дважды.  Такие ошибки можно использовать для обхода схем разрешенных списков путем введения опасных входных данных после их проверки. </solution>
	<reference>http://projects.webappsec.org/Null-Byte-Injection</reference>
	<reference>http://cwe.mitre.org/data/definitions/158.html</reference>
</vuln_item_wasc_28>

<vuln_items>wasc_29</vuln_items>
<vuln_item_wasc_29>
	<alert> LDAP  Внедрение</alert>
	<desc>Инъекция LDAP - это метод атаки, используемый для использования веб-сайтов, которые создают операторы LDAP из введенных пользователем данных. 

Облегченный протокол доступа к каталогам (LDAP) - это протокол открытого стандарта как для запросов, так и для управления службами каталогов X.500.  Протокол LDAP работает с транспортными протоколами Интернета, такими как TCP.  Веб-приложения могут использовать вводимые пользователем данные для создания пользовательских операторов LDAP для запросов динамических веб-страниц. 

Когда веб-приложению не удается должным образом очистить вводимые пользователем данные, злоумышленник может изменить конструкцию оператора LDAP.  Когда злоумышленник может изменить инструкцию LDAP, процесс будет запущен с теми же разрешениями, что и компонент, выполнивший команду.  (например, сервер базы данных, сервер веб-приложений, веб-сервер и т. д.).  Это может вызвать серьезные проблемы с безопасностью, когда разрешения предоставляют права запрашивать, изменять или удалять что-либо внутри дерева LDAP.  Те же передовые методы эксплуатации, которые доступны в SQL Injection, могут быть аналогичным образом применены и в LDAP Injection. </desc>
	<solution>Предположим, что весь ввод злонамерен.  Используйте соответствующую комбинацию черных списков и белых списков, чтобы нейтрализовать синтаксис LDAP от ввода, управляемого пользователем. </solution>
	<reference>http://projects.webappsec.org/LDAP-Injection</reference>
	<reference>http://cwe.mitre.org/data/definitions/90.html</reference>
</vuln_item_wasc_29>

<vuln_items>wasc_30</vuln_items>
<vuln_item_wasc_30>
	<alert>Внедрение почтовых команд </alert>
	<desc>Внедрение почтовых команд - это метод атаки, используемый для использования почтовых серверов и приложений веб-почты, которые создают операторы IMAP / SMTP из введенных пользователем данных, которые не были должным образом очищены.  В зависимости от типа утверждения, которое использует злоумышленник, мы встречаем два типа инъекций: IMAP и SMTP Injection.  Внедрение IMAP / SMTP может позволить получить доступ к почтовому серверу, к которому у вас раньше не было доступа.  В некоторых случаях к этим внутренним системам не применяется такой же уровень защиты инфраструктуры, как к большинству интерфейсных веб-серверов.  Следовательно, злоумышленники могут обнаружить, что почтовый сервер дает лучшие результаты с точки зрения эксплуатации.  С другой стороны, этот метод позволяет обойти возможные ограничения, которые могут существовать на уровне приложения (CAPTCHA, максимальное количество запросов и т. Д.). </desc>
	<solution>Поймите все потенциальные области, в которых ненадежные входные данные могут попасть в ваше программное обеспечение: параметры или аргументы, файлы cookie, все, что считывается из сети, переменные среды, заголовки запросов, а также контент, компоненты URL, электронная почта, файлы, базы данных и любые внешние системы. которые предоставляют данные приложению.  Выполняйте проверку ввода на четко определенных интерфейсах. 

Предположим, что весь ввод злонамерен.  Используйте стратегию проверки ввода «принять заведомо исправный» (т. е. Использовать разрешенный список).  Отклоняйте любой ввод, который не строго соответствует спецификациям, или преобразуйте его во что-то, что соответствует.  Используйте список запрета, чтобы отклонить любые неожиданные входные данные и обнаружить потенциальные атаки. 

Не полагайтесь исключительно на проверку списка запретов для обнаружения вредоносных входных данных или кодирования выходных данных.  Существует слишком много способов кодирования одного и того же символа, поэтому вы, вероятно, пропустите некоторые варианты. 

Непосредственно преобразуйте свой тип ввода в ожидаемый тип данных, например, используя функцию преобразования, которая переводит строку в число.  После преобразования в ожидаемый тип данных убедитесь, что входные значения попадают в ожидаемый диапазон допустимых значений и что сохраняется согласованность нескольких полей. 

Перед проверкой входные данные должны быть декодированы и канонизированы в текущее внутреннее представление приложения.  Убедитесь, что ваше приложение случайно не декодирует один и тот же ввод дважды.  Такие ошибки можно использовать для обхода схем разрешенных списков путем введения опасных входных данных после их проверки.  Используйте библиотеки, такие как элемент управления канонизацией OWASP ESAPI. 

Рассмотрите возможность повторной канонизации, пока ваш ввод больше не изменится.  Это позволит избежать двойного декодирования и подобных сценариев, но может непреднамеренно изменить входные данные, которым разрешено содержать правильно закодированный опасный контент. 

При обмене данными между компонентами убедитесь, что оба компонента используют одинаковую кодировку символов.  Убедитесь, что на каждом интерфейсе применяется правильная кодировка.  Явно установите кодировку, которую вы используете, когда протокол позволяет вам это сделать. 

Если ваше приложение объединяет данные из нескольких источников, выполните проверку после объединения источников.  Отдельные элементы данных могут пройти этап проверки, но нарушить намеченные ограничения после того, как они были объединены. </solution>
	<reference>http://projects.webappsec.org/Mail-Command-Injection</reference>
	<reference>http://cwe.mitre.org/data/definitions/88.html</reference>
</vuln_item_wasc_30>

<vuln_items>wasc_31</vuln_items>
<vuln_item_wasc_31>
	<alert>Управление ОС </alert>
	<desc>OS Commanding - это метод атаки, используемый для несанкционированного выполнения команд операционной системы. 

Управление ОС является прямым результатом смешения доверенного кода и ненадежных данных.  Эта атака возможна, когда приложение принимает ненадежные входные данные для создания команд операционной системы небезопасным образом, включая неправильную очистку данных и / или неправильный вызов внешних программ.  В OS Commanding выполняемые злоумышленником команды будут выполняться с теми же привилегиями, что и компонент, выполнивший команду (например, сервер базы данных, сервер веб-приложений, веб-сервер, оболочка, приложение).  Поскольку команды выполняются с привилегиями исполняемого компонента, злоумышленник может использовать это, чтобы получить доступ или повредить части, которые иным образом недоступны (например, каталоги и файлы операционной системы). </desc>
	<solution>По возможности используйте вызовы библиотеки, а не внешние процессы, чтобы воссоздать желаемую функциональность. 

Запустите свой код в «тюрьме» или подобной среде песочницы, которая устанавливает строгие границы между процессом и операционной системой.  Это может эффективно ограничить, к каким файлам можно получить доступ в конкретном каталоге или какие команды могут выполняться вашим программным обеспечением. 

Примеры уровня ОС включают chroot jail Unix, AppArmor и SELinux.  В общем, управляемый код может обеспечить некоторую защиту.  Например, java.io.FilePermission в Java SecurityManager позволяет вам указывать ограничения на файловые операции. 
Это может быть невыполнимым решением, и оно только ограничивает влияние на операционную систему; остальная часть вашего приложения все еще может быть скомпрометирована. 

Для любых данных, которые будут использоваться для генерации команды, которая должна быть выполнена, держите как можно большую часть этих данных вне внешнего контроля.  Например, в веб-приложениях это может потребовать сохранения команды локально в состоянии сеанса вместо отправки ее клиенту в скрытом поле формы. 

Используйте проверенную библиотеку или фреймворк, которые не допускают появления этой уязвимости или предоставляют конструкции, которые упрощают ее устранение. 

Например, рассмотрите возможность использования элемента управления кодированием ESAPI или аналогичного инструмента, библиотеки или инфраструктуры.  Это поможет программисту кодировать выходные данные менее подверженным ошибкам. 

Если вам необходимо использовать динамически генерируемые строки запроса или команды, несмотря на риск, правильно заключите аргументы в кавычки и избегайте любых специальных символов в этих аргументах.  Самый консервативный подход - экранировать или фильтровать все символы, которые не проходят чрезвычайно строгий список разрешений (например, все, что не является буквенно-цифровым или пробельным).  Если некоторые специальные символы все еще необходимы, например, пробел, заключите каждый аргумент в кавычки после этапа экранирования / фильтрации.  Будьте осторожны с инъекцией аргументов.

Если выполняемая программа позволяет указывать аргументы во входном файле или из стандартного ввода, рассмотрите возможность использования этого режима для передачи аргументов вместо командной строки. 

Если возможно, используйте структурированные механизмы, которые автоматически обеспечивают разделение данных и кода.  Эти механизмы могут обеспечивать соответствующее цитирование, кодирование и проверку автоматически, вместо того, чтобы полагаться на разработчика, предоставляющего эту возможность в каждой точке, где генерируются выходные данные. 

Некоторые языки предлагают несколько функций, которые можно использовать для вызова команд.  По возможности идентифицируйте любую функцию, которая вызывает командную оболочку, используя одну строку, и замените ее функцией, требующей отдельных аргументов.  Эти функции обычно выполняют соответствующие кавычки и фильтрацию аргументов.  Например, в C функция system () принимает строку, содержащую всю команду, которая должна быть выполнена, тогда как для execl (), execve () и других требуется массив строк, по одной для каждого аргумента.  В Windows CreateProcess () принимает только одну команду за раз.  В Perl, если system () предоставлен с массивом аргументов, он будет заключать в кавычки каждый из аргументов. 

Предположим, что весь ввод злонамерен.  Используйте стратегию проверки входных данных «принять заведомо исправные», т. е. Используйте разрешенный список допустимых входных данных, которые строго соответствуют спецификациям.  Отклоняйте любой ввод, который не строго соответствует спецификациям, или преобразуйте его во что-то, что соответствует.  Не полагайтесь исключительно на поиск вредоносных или искаженных входных данных (т. е. Не полагайтесь на список запрещенных).  Однако списки запрета могут быть полезны для обнаружения потенциальных атак или определения того, какие входные данные настолько искажены, что их следует сразу отклонить. 

При выполнении проверки ввода учитывайте все потенциально важные свойства, включая длину, тип ввода, полный диапазон допустимых значений, отсутствующие или дополнительные вводы, синтаксис, согласованность между связанными полями и соответствие бизнес-правилам.  В качестве примера логики бизнес-правила «лодка» может быть синтаксически допустимой, потому что она содержит только буквенно-цифровые символы, но недействительна, если вы ожидаете такие цвета, как «красный» или «синий». 

При построении командных строк ОС используйте строгие разрешающие списки, которые ограничивают набор символов на основе ожидаемого значения параметра в запросе.  Это косвенно ограничит масштаб атаки, но этот метод менее важен, чем правильное кодирование вывода и экранирование. 

Обратите внимание, что правильное кодирование вывода, экранирование и цитирование являются наиболее эффективным решением для предотвращения внедрения команд ОС, хотя проверка ввода может обеспечить некоторую глубинную защиту.  Это потому, что он эффективно ограничивает то, что будет отображаться на выходе.  Проверка ввода не всегда предотвращает внедрение команд ОС, особенно если требуется поддерживать текстовые поля произвольной формы, которые могут содержать произвольные символы.  Например, при вызове почтовой программы вам может потребоваться разрешить поле темы содержать опасные в противном случае вводы, такие как ";" и символы ">", которые необходимо экранировать или обрабатывать иным образом.  В этом случае удаление символа может снизить риск внедрения команды ОС, но приведет к некорректному поведению, поскольку поле темы не будет записано так, как задумал пользователь.  Это может показаться незначительным неудобством, но это может быть более важным, когда программа полагается на хорошо структурированные строки темы для передачи сообщений другим компонентам. 

Даже если вы допустили ошибку при проверке (например, забыли одно из 100 полей ввода), соответствующая кодировка все равно может защитить вас от атак на основе инъекций.  Пока это не выполняется изолированно, проверка входных данных по-прежнему является полезным методом, поскольку она может значительно уменьшить поверхность атаки, позволить вам обнаруживать некоторые атаки и обеспечить другие преимущества безопасности, которые не учитываются при правильном кодировании. </solution>
	<reference>http://projects.webappsec.org/OS-Commanding</reference>
	<reference>http://cwe.mitre.org/data/definitions/78.html</reference>
</vuln_item_wasc_31>

<vuln_items>wasc_32</vuln_items>
<vuln_item_wasc_32>
	<alert>Маршрут в объезд </alert>
	<desc>Протокол WS-Routing (WS-Routing) - это протокол для обмена сообщениями SOAP от исходного отправителя сообщения до конечного получателя, обычно через набор посредников.  Протокол WS-Routing реализован как расширение SOAP и встроен в заголовок SOAP.  WS-Routing часто используется для обеспечения способа направления XML-трафика через сложные среды и транзакции, позволяя промежуточным промежуточным станциям на XML-пути назначать инструкции маршрутизации XML-документу. 

Объезды маршрутизации - это тип атаки «человек посередине», при которой посредники могут быть введены или «захвачены» для маршрутизации конфиденциальных сообщений во внешнее расположение.  Информация о маршрутизации (либо в заголовке HTTP, либо в заголовке WS-Routing) может быть изменена в пути, а следы маршрутизации могут быть удалены из заголовка и сообщения, чтобы принимающее приложение не знало, что произошел обход маршрутизации.  The header and the insertion of header objects is often less protected than the message; this is due to the fact that the header is used as a catch all for metadata about the transaction such as authentication, routing, formatting, schema, canonicalization, namespaces, etc. Also, many processes may be involved in adding to/processing the header of an XML document. In many implementations the routing info can come from an external web service (using WS-Referral for example) that provides the specific routing for the transaction.

WS-Addressing is a newer standard published by the W3C to provide routing functionality to SOAP messages. One of the key differences between WS-Routing and WS-Addressing is that WS-Addressing only provides the next location in the route. While little research has been done into the susceptibility of WS-Addressing to Routing Detour Attack, at least one paper (see reference #6 below) suggests that WS-Addressing is vulnerable to Routing Detour as well.</desc>
	<solution>Всегда полностью аутентифицируйте оба конца любого канала связи. 

Придерживайтесь принципа полной медиации. 

Сертификат связывает личность с криптографическим ключом для аутентификации взаимодействующей стороны.  Часто сертификат принимает зашифрованную форму хэша идентичности субъекта, открытого ключа и такой информации, как время выпуска или истечения срока действия с использованием закрытого ключа эмитента.  Сертификат может быть подтвержден путем расшифровки сертификата с помощью открытого ключа эмитента.  Смотри также цепочки подписей сертификатов X.509 и структуру сертификации PGP. </solution>
	<reference>http://projects.webappsec.org/Routing-Detour</reference>
	<reference>http://cwe.mitre.org/data/definitions/300.html</reference>
</vuln_item_wasc_32>

<vuln_items>wasc_33</vuln_items>
<vuln_item_wasc_33>
	<alert>Обход Пути </alert>
	<desc>Атака с обходом пути позволяет злоумышленнику получить доступ к файлам, каталогам и командам, которые потенциально находятся за пределами корневого каталога веб-документа.  Злоумышленник может манипулировать URL-адресом таким образом, чтобы веб-сайт выполнял или раскрывал содержимое произвольных файлов в любом месте веб-сервера.  Любое устройство, предоставляющее интерфейс на основе HTTP, потенциально уязвимо для обхода пути. 

Большинство веб-сайтов ограничивают доступ пользователей к определенной части файловой системы, обычно называемой «корневым каталогом веб-документа» или «корневым каталогом CGI».  Эти каталоги содержат файлы, предназначенные для доступа пользователей, и исполняемые файлы, необходимые для работы веб-приложений.  Чтобы получить доступ к файлам или выполнить команды в любом месте файловой системы, атаки Path Traversal будут использовать возможности последовательностей специальных символов. 

Самая простая атака с обходом пути использует последовательность специальных символов «../» для изменения местоположения ресурса, запрашиваемого в URL-адресе.  Хотя большинство популярных веб-серверов не позволяют этой методике экранировать корень веб-документа, альтернативные кодировки последовательности «../» могут помочь обойти фильтры безопасности.  Эти варианты метода включают допустимую и недопустимую кодировку Unicode ("..% u2216" или "..% c0% af") символа прямой косой черты, символы обратной косой черты (".. \") на серверах под управлением Windows, кодирование URL символы "% 2e% 2e% 2f") и двойное кодирование URL ("..% 255c") символа обратной косой черты. 

Даже если веб-сервер правильно ограничивает попытки обхода пути в пути URL, само веб-приложение может быть уязвимо из-за неправильной обработки вводимых пользователем данных.  Это обычная проблема веб-приложений, которые используют механизмы шаблонов или загружают статический текст из файлов.  В вариантах атаки исходное значение параметра URL заменяется именем файла одного из динамических скриптов веб-приложения.  Следовательно, результаты могут раскрыть исходный код, поскольку файл интерпретируется как текст, а не как исполняемый сценарий.  В этих методах часто используются дополнительные специальные символы, такие как точка (".")  для отображения списка текущего рабочего каталога или символов «% 00» NULL, чтобы обойти элементарные проверки расширений файлов. </desc>
	<solution>Предположим, что весь ввод злонамерен.  Используйте стратегию проверки входных данных «принять заведомо исправные», т. е. Используйте разрешенный список допустимых входных данных, которые строго соответствуют спецификациям.  Отклоняйте любой ввод, который не строго соответствует спецификациям, или преобразуйте его во что-то, что соответствует.  Не полагайтесь исключительно на поиск вредоносных или искаженных входных данных (т. е. Не полагайтесь на список запрещенных).  Однако списки запрета могут быть полезны для обнаружения потенциальных атак или определения того, какие входные данные настолько искажены, что их следует сразу отклонить. 

При выполнении проверки ввода учитывайте все потенциально важные свойства, включая длину, тип ввода, полный диапазон допустимых значений, отсутствующие или дополнительные вводы, синтаксис, согласованность между связанными полями и соответствие бизнес-правилам.  В качестве примера логики бизнес-правила «лодка» может быть синтаксически допустимой, потому что она содержит только буквенно-цифровые символы, но недействительна, если вы ожидаете такие цвета, как «красный» или «синий». 

Для имен файлов используйте строгие списки разрешений, которые ограничивают используемый набор символов.  Если возможно, разрешите только один "." в имени файла, чтобы избежать слабых мест, и исключить разделители каталогов, такие как «/».  Используйте разрешенный список допустимых расширений файлов. 

Предупреждение: если вы попытаетесь очистить свои данные, сделайте так, чтобы конечный результат не был в форме, которая может быть опасной.  Механизм очистки может удалить такие символы, как "." а также ';' который может потребоваться для некоторых эксплойтов.  Злоумышленник может попытаться обмануть механизм очистки, чтобы «очистить» данные до опасной формы.  Предположим, злоумышленник вводит '.' внутри имени файла (например, "sensi.tiveFile"), а механизм очистки удаляет символ, в результате чего получается допустимое имя файла, "sensitiveFile".  Если теперь предполагается, что входные данные безопасны, файл может быть скомпрометирован.  

Перед проверкой входные данные должны быть декодированы и канонизированы в текущее внутреннее представление приложения.  Убедитесь, что ваше приложение не декодирует один и тот же ввод дважды.  Такие ошибки можно использовать для обхода схем разрешенных списков путем введения опасных входных данных после их проверки. 

Используйте встроенную функцию канонизации пути (например, realpath () в C), которая создает каноническую версию имени пути, которая эффективно удаляет последовательности «..» и символические ссылки. 

Запустите свой код, используя самые низкие привилегии, необходимые для выполнения необходимых задач.  Если возможно, создайте изолированные учетные записи с ограниченными правами, которые используются только для одной задачи.  Таким образом, успешная атака не предоставит злоумышленнику немедленный доступ к остальному программному обеспечению или его среде.  Например, приложениям баз данных редко требуется запускать от имени администратора базы данных, особенно в повседневных операциях. 

Когда набор допустимых объектов, таких как имена файлов или URL-адресов, ограничен или известен, создайте сопоставление из набора фиксированных входных значений (например, числовых идентификаторов) с фактическими именами файлов или URL-адресами и отклоните все остальные входные данные. 

Запустите свой код в «тюрьме» или подобной среде песочницы, которая устанавливает строгие границы между процессом и операционной системой.  Это может эффективно ограничить, к каким файлам можно получить доступ в конкретном каталоге или какие команды могут выполняться вашим программным обеспечением. 

Примеры уровня ОС включают chroot jail Unix, AppArmor и SELinux.  В общем, управляемый код может обеспечить некоторую защиту.  Например, java.io.FilePermission в Java SecurityManager позволяет вам указывать ограничения на файловые операции. 

Это может быть невыполнимым решением, и оно только ограничивает влияние на операционную систему; остальная часть вашего приложения все еще может быть скомпрометирована. 
</solution>
	<reference>http://projects.webappsec.org/Path-Traversal</reference>
	<reference>http://cwe.mitre.org/data/definitions/22.html</reference>
</vuln_item_wasc_33>

<vuln_items>wasc_34</vuln_items>
<vuln_item_wasc_34>
	<alert>Прогнозируемое местоположение ресурса </alert>
	<desc>Предсказуемое расположение ресурса - это метод атаки, используемый для обнаружения скрытого содержимого и функций веб-сайта.  Делая обоснованные предположения с помощью грубой силы, злоумышленник может угадать имена файлов и каталогов, не предназначенные для публичного просмотра.  Подобрать имена файлов просто, потому что файлы / пути часто имеют общее соглашение об именах и находятся в стандартных местах.  Сюда могут входить временные файлы, файлы резервных копий, журналы, разделы административного сайта, файлы конфигурации, демонстрационные приложения и файлы примеров.  Эти файлы могут раскрывать конфиденциальную информацию о веб-сайте, внутреннем устройстве веб-приложения, информацию о базе данных, пароли, имена компьютеров, пути к файлам в другие конфиденциальные области и т. Д. 

Это не только поможет идентифицировать поверхность сайта, которая может привести к дополнительным уязвимостям сайта, но также может раскрыть злоумышленнику ценную информацию о среде или ее пользователях.  Предсказуемое расположение ресурса также известно как принудительный просмотр, принудительный просмотр, перечисление файлов и перечисление каталогов. </desc>
	<solution>Примените соответствующие разрешения управления доступом для каждого доступа ко всем ограниченным URL-адресам, скриптам или файлам. 

Рассмотрите возможность использования фреймворков на основе MVC, таких как Struts. </solution>
	<reference>http://projects.webappsec.org/Predictable-Resource-Location</reference>
	<reference>http://cwe.mitre.org/data/definitions/425.html</reference>
</vuln_item_wasc_34>

<vuln_items>wasc_35</vuln_items>
<vuln_item_wasc_35>
	<alert>Злоупотребление массивом SOAP </alert>
	<desc>Массивы XML SOAP являются частой целью злонамеренных действий.  Массивы SOAP определяются как имеющие тип «SOAP-ENC: Array» или производный от него тип.  Массивы SOAP имеют одно или несколько измерений (ранг), члены которых различаются порядковым номером.  Значение массива представлено в виде серии элементов, отражающих массив, причем элементы отображаются в порядке возрастания.  Для многомерных массивов размер справа изменяется наиболее быстро.  Каждый элемент-член называется независимым элементом.  Веб-служба, которая ожидает массив, может стать целью XML-атаки DoS, вынуждая сервер SOAP создать огромный массив в памяти машины, тем самым вызывая состояние DoS на машине из-за предварительного выделения памяти. </desc>
	<solution> Выполните адекватную проверку ввода по любому значению, которое влияет на объем выделяемой памяти.  Определите подходящую стратегию обработки запросов, превышающих лимит, и рассмотрите возможность поддержки параметра конфигурации, чтобы администратор мог при необходимости увеличить объем используемой памяти. 

Запустите вашу программу, используя системные ограничения ресурсов для памяти.  Это по-прежнему может привести к сбою программы или выходу из нее, но влияние на остальную систему будет сведено к минимуму. </solution>
	<reference>http://projects.webappsec.org/SOAP-Array-Abuse</reference>
	<reference>http://cwe.mitre.org/data/definitions/789.html</reference>
</vuln_item_wasc_35>

<vuln_items>wasc_36</vuln_items>
<vuln_item_wasc_36>
	<alert>SSI инъекция </alert>
	<desc>
SSI Injection (Server-side Include) - это метод эксплойта на стороне сервера, который позволяет злоумышленнику отправить код в веб-приложение, которое позже будет выполняться локально веб-сервером.  SSI Injection exploits a web application's failure to sanitize user-supplied data before they are inserted into a server-side interpreted HTML file.

Before serving an HTML web page, a web server may parse and execute Server-side Include statements before providing it to the client. In some cases (e.g. message boards, guest books, or content management systems), a web application will insert user-supplied data into the source of a web page.

If an attacker submits a Server-side Include statement, he may have the ability to execute arbitrary operating system commands, or include a restricted file's contents the next time the page is served. This is performed at the permission level of the web server user.</desc>
	<solution>Отключите выполнение SSI на страницах, которые этого не требуют.  Для страниц, требующих SSI, убедитесь, что вы выполнили следующие проверки
- Включите только те директивы SSI, которые необходимы для этой страницы, и отключите все остальные. 
- Сущность HTML кодирует предоставленные пользователем данные перед их передачей на страницу с разрешениями на выполнение SSI. 
- Используйте SUExec, чтобы страница выполнялась как владелец файла, а не как пользователь веб-сервера. </solution>
	<reference>http://projects.webappsec.org/SSI-Injection</reference>
	<reference/>
</vuln_item_wasc_36>

<vuln_items>wasc_37</vuln_items>
<vuln_item_wasc_37>
	<alert>Фиксация сеанса </alert>
	<desc>Фиксация сеанса - это метод атаки, при котором для идентификатора сеанса пользователя устанавливается явное значение.  В зависимости от функциональности целевого веб-сайта можно использовать ряд методов для «исправления» значения идентификатора сеанса.  Эти методы варьируются от эксплойтов межсайтового скриптинга до засыпки веб-сайта ранее сделанными HTTP-запросами.  После того, как идентификатор сеанса пользователя будет исправлен, злоумышленник будет ждать, пока этот пользователь войдет в систему.  Как только пользователь сделает это, злоумышленник использует предварительно определенное значение идентификатора сеанса, чтобы принять тот же сетевой идентификатор. 

Вообще говоря, когда дело доходит до значений идентификаторов, существует два типа систем управления сеансами.  Первый тип - это «разрешительные» системы, которые позволяют веб-браузерам указывать любой идентификатор.  Второй тип - это «строгие» системы, которые принимают только значения, сгенерированные на стороне сервера.  В разрешительных системах произвольные идентификаторы сеанса поддерживаются без связи с веб-сайтом.  Строгие системы требуют, чтобы злоумышленник поддерживал «ловушку-сессию» с периодическим контактом с веб-сайтом, предотвращая тайм-ауты бездействия. 

Без активной защиты от фиксации сеанса атака может быть проведена против любого веб-сайта, который использует сеансы для идентификации пользователей, прошедших проверку подлинности.  Веб-сайты, использующие идентификаторы сеансов, обычно основаны на файлах cookie, но также используются URL-адреса и скрытые поля формы.  К сожалению, легче всего атаковать сеансы на основе файлов cookie.  Большинство выявленных в настоящее время методов атак направлены на фиксацию файлов cookie. 

В отличие от кражи идентификаторов сеансов пользователей после того, как они вошли на веб-сайт, Session Fixation предоставляет гораздо более широкое окно возможностей.  Активная часть атаки происходит до входа пользователя в систему. </desc>
	<solution>Аннулировать все существующие идентификаторы сеанса до авторизации нового сеанса пользователя

Для таких платформ, как ASP, которые не генерируют новые значения для файлов cookie с идентификатором сеанса, используйте дополнительный файл cookie.  В этом подходе установите вторичный файл cookie в браузере пользователя на случайное значение и задайте такое же значение переменной сеанса.  Если переменная сеанса и значение cookie никогда не совпадают, сделайте сеанс недействительным и заставьте пользователя снова войти в систему. </solution>
	<reference>http://projects.webappsec.org/Session-Fixation</reference>
	<reference>http://cwe.mitre.org/data/definitions/384.html</reference>
</vuln_item_wasc_37>

<vuln_items>wasc_38</vuln_items>
<vuln_item_wasc_38>
	<alert>Злоупотребление URL-адресом Redirector </alert>
	<desc>Перенаправители URL-адресов представляют собой общие функции, используемые веб-сайтами для пересылки входящего запроса на альтернативный ресурс.  Это может быть сделано по разным причинам и часто делается для того, чтобы разрешить перемещение ресурсов в структуре каталогов и избежать нарушения функциональности для пользователей, которые запрашивают ресурс в его предыдущем расположении.  Перенаправители URL-адресов также могут использоваться для реализации балансировки нагрузки, использования сокращенных URL-адресов или записи исходящих ссылок.  Именно эта последняя реализация часто используется в фишинговых атаках, как описано в примере ниже.  Перенаправители URL-адресов не обязательно представляют собой прямую уязвимость системы безопасности, но могут использоваться злоумышленниками, пытающимися заставить жертв социальной инженерии поверить в то, что они переходят на сайт, отличный от истинного пункта назначения. </desc>
	<solution>Предположим, что весь ввод злонамерен.  Используйте стратегию проверки входных данных «принять заведомо исправные», т. е. Используйте разрешенный список допустимых входных данных, которые строго соответствуют спецификациям.  Отклоняйте любой ввод, который не строго соответствует спецификациям, или преобразуйте его во что-то, что соответствует.  Не полагайтесь исключительно на поиск вредоносных или искаженных входных данных (т. е. Не полагайтесь на список запрещенных).  Однако списки запрета могут быть полезны для обнаружения потенциальных атак или определения того, какие входные данные настолько искажены, что их следует сразу отклонить. 

При выполнении проверки ввода учитывайте все потенциально важные свойства, включая длину, тип ввода, полный диапазон допустимых значений, отсутствующие или дополнительные вводы, синтаксис, согласованность между связанными полями и соответствие бизнес-правилам.  В качестве примера логики бизнес-правила «лодка» может быть синтаксически допустимой, потому что она содержит только буквенно-цифровые символы, но недействительна, если вы ожидаете такие цвета, как «красный» или «синий». 

Используйте разрешенный список разрешенных URL-адресов или доменов, которые будут использоваться для перенаправления. 

Используйте промежуточную страницу отказа от ответственности, которая дает пользователю четкое предупреждение о том, что он покидает ваш сайт.  Установите длительный тайм-аут до того, как произойдет перенаправление, или заставьте пользователя щелкнуть ссылку.  Будьте осторожны, чтобы избежать проблем XSS при создании страницы заявления об отказе от ответственности. 

Когда набор допустимых объектов, таких как имена файлов или URL-адресов, ограничен или известен, создайте сопоставление из набора фиксированных входных значений (например, числовых идентификаторов) с фактическими именами файлов или URL-адресами и отклоните все остальные входные данные. 

Например, идентификатор 1 может отображаться на «/login.asp», а идентификатор 2 может отображаться на «http://www.example.com/».  Такие функции, как ESAPI AccessReferenceMap, предоставляют эту возможность. 

Поймите все потенциальные области, в которых ненадежные входные данные могут попасть в ваше программное обеспечение: параметры или аргументы, файлы cookie, все, что считывается из сети, переменные среды, обратный поиск DNS, результаты запросов, заголовки запросов, компоненты URL, электронная почта, файлы, базы данных и любые внешние системы, которые предоставляют данные приложению.  Помните, что такие входные данные могут быть получены косвенно через вызовы API. 

Многие проблемы с открытым перенаправлением возникают из-за того, что программист предполагал, что определенные входные данные не могут быть изменены, такие как файлы cookie и скрытые поля формы. </solution>
	<reference>http://projects.webappsec.org/URL-Redirector-Abuse</reference>
	<reference>http://cwe.mitre.org/data/definitions/601.html</reference>
</vuln_item_wasc_38>

<vuln_items>wasc_39</vuln_items>
<vuln_item_wasc_39>
	<alert> XPath Инъекция</alert>
	<desc>XPath Injection - это метод атаки, используемый для использования приложений, которые создают запросы XPath (XML Path Language) из введенных пользователем данных для запроса или навигации по XML-документам.  Он может использоваться непосредственно приложением для запроса XML-документа как часть более крупной операции, такой как применение XSLT-преобразования к XML-документу или применение XQuery к XML-документу.  Синтаксис XPath имеет некоторое сходство с SQL-запросом, и действительно, с помощью XPath можно формировать SQL-подобные запросы к XML-документу. 

Если приложение использует построение запроса XPath во время выполнения, встраивая в запрос небезопасный пользовательский ввод, злоумышленник может ввести данные в запрос, так что вновь сформированный запрос будет анализироваться способом, отличным от намерений программиста. </desc>
	<solution>Используйте параметризованные запросы XPath (например, с помощью XQuery).  Это поможет обеспечить разделение между плоскостью данных и плоскостью управления. 

Правильно проверяйте вводимые пользователем данные.  Отклоняйте данные, где это необходимо, фильтруйте, где это необходимо, и избегайте, когда это необходимо.  Убедитесь, что ввод, который будет использоваться в запросах XPath, безопасен в этом контексте. </solution>
	<reference>http://projects.webappsec.org/XPath-Injection</reference>
	<reference>http://cwe.mitre.org/data/definitions/643.html</reference>
</vuln_item_wasc_39>

<vuln_items>wasc_40</vuln_items>
<vuln_item_wasc_40>
	<alert>Недостаточная проверка процесса </alert>
	<desc>Недостаточная проверка процесса происходит, когда веб-приложению не удается помешать злоумышленнику обойти намеченный поток или бизнес-логику приложения.  В реальном мире недостаточная проверка процесса привела к неэффективному контролю доступа и денежным потерям. 

Существует два основных типа процессов, требующих проверки: управление потоком и бизнес-логика. 

«Управление потоком» относится к многоэтапным процессам, которые требуют, чтобы каждый шаг выполнялся пользователем в определенном порядке.  Когда злоумышленник выполняет шаг неправильно или не по порядку, элементы управления доступом могут быть обойдены, и может возникнуть ошибка целостности приложения.  Примеры многоэтапных процессов включают банковский перевод, восстановление пароля, оформление покупки и регистрацию учетной записи. 

«Бизнес-логика» относится к контексту, в котором процесс будет выполняться в соответствии с бизнес-требованиями.  Использование слабых мест бизнес-логики требует знания бизнеса; если для его использования не нужны знания, то, скорее всего, это не ошибка бизнес-логики.  По этой причине типичные меры безопасности, такие как сканирование и проверка кода, не обнаруживают этот класс слабых мест.  Один из подходов к тестированию предлагается OWASP в их Руководстве по тестированию. </desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/Insufficient-Process-Validation</reference>
	<reference/>
</vuln_item_wasc_40>

<vuln_items>wasc_41</vuln_items>
<vuln_item_wasc_41>
	<alert>Раздутие атрибута XML </alert>
	<desc>XML Attribute Blowup - это атака отказа в обслуживании против анализаторов XML.  Злоумышленник предоставляет вредоносный XML-документ, который уязвимые парсеры XML обрабатывают очень неэффективно, что приводит к чрезмерной загрузке процессора.  Суть атаки заключается во включении множества атрибутов в один и тот же узел XML.  Уязвимые синтаксические анализаторы XML неэффективно управляют атрибутами (например, в контейнере данных, для которого вставка нового атрибута имеет время выполнения O (n)), что приводит к нелинейному (в данном примере квадратичному, т.е.  O (n2)) общее время выполнения, что приводит к отказу в обслуживании из-за нехватки ресурсов ЦП. </desc>
	<solution>Разработайте механизмы дросселирования в архитектуре системы.  Лучшая защита - это ограничить количество ресурсов, которые неавторизованный пользователь может использовать.  Надежная модель аутентификации и контроля доступа в первую очередь поможет предотвратить подобные атаки.  Приложение для входа в систему должно быть максимально защищено от DoS-атак.  Ограничение доступа к базе данных, возможно, путем кэширования наборов результатов, может помочь минимизировать затрачиваемые ресурсы.  Чтобы еще больше ограничить вероятность DoS-атаки, рассмотрите возможность отслеживания скорости запросов, полученных от пользователей, и блокировки запросов, которые превышают определенный порог скорости. 

Смягчение атак на исчерпание ресурсов требует, чтобы целевая система:
  * распознает атаку и запрещает этому пользователю дальнейший доступ в течение определенного периода времени, или
  * равномерно регулирует все запросы, чтобы усложнить потребление ресурсов быстрее, чем их можно будет снова освободить.  

Первое из этих решений само по себе является проблемой, поскольку может позволить злоумышленникам предотвратить использование системы конкретным действующим пользователем.  Если злоумышленник выдает себя за действительного пользователя, он может предотвратить доступ пользователя к рассматриваемому серверу. 

Второе решение просто сложно внедрить эффективно - и даже при правильном выполнении оно не дает полного решения.  Это просто заставляет атаку требовать больше ресурсов со стороны злоумышленника. 

Убедитесь, что протоколы имеют определенные ограничения масштаба. 

Убедитесь, что все сбои в распределении ресурсов переводят систему в безопасное состояние. </solution>
	<reference>http://projects.webappsec.org/XML-Attribute-Blowup</reference>
	<reference>http://cwe.mitre.org/data/definitions/400.html</reference>
</vuln_item_wasc_41>

<vuln_items>wasc_42</vuln_items>
<vuln_item_wasc_42>
	<alert>Злоупотребление функциональностью </alert>
	<desc>Злоупотребление функциональностью - это метод атаки, при котором используются собственные функции и функции веб-сайта для атаки на себя или других.  Злоупотребление функциональностью можно описать как злоупотребление предполагаемой функциональностью приложения для достижения нежелательного результата.  Эти атаки приводят к различным результатам, таким как потребление ресурсов, обход средств контроля доступа или утечка информации.  Потенциал и уровень злоупотреблений будут варьироваться от веб-сайта к веб-сайту и от приложения к приложению.  Атаки со злоупотреблением функциональностью часто представляют собой комбинацию других типов атак и / или используют другие векторы атак. </desc>
	<solution>Всегда используйте API указанным образом. </solution>
	<reference>http://projects.webappsec.org/Abuse-of-Functionality</reference>
	<reference>http://cwe.mitre.org/data/definitions/227.html</reference>
</vuln_item_wasc_42>

<vuln_items>wasc_43</vuln_items>
<vuln_item_wasc_43>
	<alert>Внешние объекты XML </alert>
	<desc>Этот метод использует преимущества XML для динамического создания документов во время обработки.  Сообщение XML может либо предоставлять данные явно, либо указывать на URI, в котором данные существуют.  В методе атаки внешние объекты могут заменить значение объекта вредоносными данными, альтернативными ссылками или могут поставить под угрозу безопасность данных, к которым сервер / приложение XML имеет доступ. 
	Злоумышленники также могут использовать внешние объекты, чтобы сервер веб-служб загружал вредоносный код или контент на сервер для использования во вторичных или последующих атаках. </desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/XML-External-Entities</reference>
	<reference/>
</vuln_item_wasc_43>

<vuln_items>wasc_44</vuln_items>
<vuln_item_wasc_44>
	<alert>Расширение сущности XML </alert>
	<desc>Атака расширения XML Entity использует возможность XML DTD, которая позволяет создавать настраиваемые макросы, называемые объектами, которые можно использовать во всем документе.  Рекурсивно определяя набор настраиваемых сущностей в верхней части документа, злоумышленник может подавить синтаксические анализаторы, которые пытаются полностью разрешить сущности, заставляя их почти бесконечно повторять эти рекурсивные определения. 

Вредоносное сообщение XML используется для принудительного расширения рекурсивного объекта (или другой повторяющейся обработки), которая полностью использует доступные ресурсы сервера. </desc>
	<solution>Если возможно, запретите использование DTD или используйте синтаксический анализатор XML, который ограничивает расширение рекурсивных сущностей DTD. 

Перед синтаксическим анализом файлов XML со связанными DTD просканируйте объявления рекурсивных сущностей и не продолжайте синтаксический анализ потенциально взрывоопасного содержимого. </solution>
	<reference>http://projects.webappsec.org/XML-Entity-Expansion</reference>
	<reference>http://cwe.mitre.org/data/definitions/776.html</reference>
</vuln_item_wasc_44>

<vuln_items>wasc_45</vuln_items>
<vuln_item_wasc_45>
	<alert>Снятие отпечатков пальцев </alert>
	<desc>Наиболее распространенная методология для злоумышленников - сначала отследить присутствие цели в сети и перечислить как можно больше информации.  Обладая этой информацией, злоумышленник может разработать точный сценарий атаки, который будет эффективно использовать уязвимость в типе / версии программного обеспечения, используемом целевым хостом. 

Многоуровневое сканирование отпечатков пальцев аналогично своему предшественнику, TCP / IP Fingerprinting (со сканером, таким как Nmap), за исключением того, что оно сосредоточено на прикладном уровне модели OSI, а не на транспортном уровне.  Теория, лежащая в основе этого снятия отпечатков пальцев, заключается в создании точного профиля целевой платформы, технологии программного обеспечения веб-приложений, версии серверной базы данных, конфигураций и, возможно, даже их сетевой архитектуры / топологии. </desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/Fingerprinting</reference>
	<reference/>
</vuln_item_wasc_45>

<vuln_items>wasc_46</vuln_items>
<vuln_item_wasc_46>
	<alert>Инъекция XQuery </alert>
	<desc>XQuery Injection - это вариант классической атаки SQL-инъекции против языка XML XQuery.  XQuery Injection использует неправильно проверенные данные, которые передаются командам XQuery.  Этот inturn будет выполнять команды от имени злоумышленника, к которому подпрограммы XQuery имеют доступ.  Внедрение XQuery может использоваться для перечисления элементов в среде жертвы, ввода команд на локальный хост или выполнения запросов к удаленным файлам и источникам данных.  Подобно атакам с использованием SQL-инъекций, злоумышленник туннелирует через точку входа приложения для нацеливания на уровень доступа к ресурсам. </desc>
	<solution>Используйте параметризованные запросы.  Это поможет обеспечить разделение между плоскостью данных и плоскостью управления. 

Правильно проверяйте вводимые пользователем данные.  Отклоняйте данные, где это необходимо, фильтруйте, где это необходимо, и избегайте, когда это необходимо.  Убедитесь, что ввод, который будет использоваться в запросах XQL, безопасен в этом контексте. </solution>
	<reference>http://projects.webappsec.org/XQuery-Injection</reference>
	<reference>http://cwe.mitre.org/data/definitions/652.html</reference>
</vuln_item_wasc_46>

<vuln_items>wasc_47</vuln_items>
<vuln_item_wasc_47>
	<alert>Недостаточный срок действия сеанса </alert>
	<desc>Недостаточное истечение срока сеанса происходит, когда веб-приложение разрешает злоумышленнику повторно использовать старые учетные данные сеанса или идентификаторы сеанса для авторизации.  Недостаточный срок действия сеанса увеличивает уязвимость веб-сайта для атак, которые воруют или повторно используют идентификаторы сеанса пользователя. 

Поскольку HTTP является протоколом без сохранения состояния, веб-сайты обычно используют файлы cookie для хранения идентификаторов сеансов, которые однозначно идентифицируют пользователя от запроса к запросу.  Следовательно, необходимо поддерживать конфиденциальность каждого идентификатора сеанса, чтобы предотвратить доступ нескольких пользователей к одной и той же учетной записи.  Украденный идентификатор сеанса можно использовать для просмотра учетной записи другого пользователя или выполнения мошеннической транзакции. 

Срок действия сеанса состоит из двух типов тайм-аута: бездействия и абсолютного.  Абсолютный тайм-аут определяется общим количеством времени, в течение которого сеанс может быть действительным без повторной аутентификации, а тайм-аут бездействия - это время простоя, разрешенное до того, как сеанс будет признан недействительным.  Отсутствие надлежащего истечения срока действия сеанса может увеличить вероятность успеха некоторых атак.  Длительное время истечения увеличивает шанс злоумышленника угадать действительный идентификатор сеанса.  Чем больше время истечения срока, тем больше одновременных открытых сеансов будет существовать в любой момент времени.  Чем больше пул сеансов, тем больше вероятность, что злоумышленник угадывает один случайным образом.  Хотя короткий тайм-аут неактивности сеанса не помогает, если токен используется немедленно, короткий тайм-аут помогает гарантировать, что токен сложнее захватить, пока он еще действителен. 

Веб-приложение должно аннулировать сеанс после истечения заранее определенного времени простоя (тайм-аут) и предоставлять пользователю средства для аннулирования своего собственного сеанса, т. Е. Выхода из системы; это помогает максимально сократить срок жизни идентификатора сеанса и необходимо в общей вычислительной среде, где более одного человека имеют неограниченный физический доступ к компьютеру.  Функция выхода из системы должна быть хорошо видна пользователю, явно аннулировать сеанс пользователя и запрещать повторное использование токена сеанса. </desc>
	<solution>Установите дату истечения срока действия сеансов / учетных данных. </solution>
	<reference>http://projects.webappsec.org/Insufficient-Session-Expiration</reference>
	<reference>http://cwe.mitre.org/data/definitions/613.html</reference>
</vuln_item_wasc_47>

<vuln_items>wasc_48</vuln_items>
<vuln_item_wasc_48>
	<alert>Небезопасное индексирование </alert>
	<desc>Небезопасное индексирование представляет собой угрозу конфиденциальности данных веб-сайта.  Индексирование содержимого веб-сайта с помощью процесса, который имеет доступ к файлам, которые не должны быть общедоступными, может привести к утечке информации о существовании таких файлов и об их содержании.  В процессе индексирования такая информация собирается и сохраняется процессом индексирования, который впоследствии может быть извлечен (хотя и нетривиально) определенным злоумышленником, обычно посредством серии запросов к поисковой системе.  Злоумышленник не нарушает модель безопасности поисковой системы.  Злоумышленник не нарушает модель безопасности поисковой системы. </desc>
	<solution>TBA</solution>
	<reference>http://projects.webappsec.org/Insecure-Indexing</reference>
	<reference/>
</vuln_item_wasc_48>

<vuln_items>wasc_49</vuln_items>
<vuln_item_wasc_49>
	<alert>Недостаточное восстановление пароля </alert>
	<desc>Недостаточное восстановление пароля - это когда веб-сайт позволяет злоумышленнику незаконно получить, изменить или восстановить пароль другого пользователя.  Обычные методы аутентификации веб-сайта требуют от пользователей выбора и запоминания пароля или ключевой фразы.  Пользователь должен быть единственным человеком, который знает пароль, и его необходимо точно запомнить.  Со временем способность пользователя запоминать пароль ослабевает.  Ситуация еще более усложняется, когда средний пользователь посещает 20 сайтов, требующих от них ввода пароля.   (Обзор RSA: http://news.bbc.co.uk/1/hi/technology/3639679.stm) Таким образом, восстановление пароля является важной частью обслуживания онлайн-пользователей. 

Примеры автоматизированных процессов восстановления пароля включают требование к пользователю ответить на «секретный вопрос», определенный как часть процесса регистрации пользователя.  Этот вопрос может быть выбран из списка стандартных вопросов или задан пользователем.  Другой используемый механизм - это предоставление пользователем «подсказки» во время регистрации, которая поможет пользователю вспомнить свой пароль.  Другие механизмы требуют, чтобы пользователь предоставил несколько частей личных данных, таких как номер социального страхования, домашний адрес, почтовый индекс и т. Д., Чтобы подтвердить свою личность.  После того, как пользователь подтвердит, кто он, система восстановления отобразит новый пароль или отправит ему по электронной почте. 

Считается, что веб-сайт имеет недостаточное восстановление пароля, если злоумышленник может помешать используемому механизму восстановления.  Это происходит, когда информация, необходимая для подтверждения личности пользователя для восстановления, либо легко угадывается, либо ее можно обойти.  Системы восстановления паролей могут быть скомпрометированы с помощью атак методом перебора, внутренних слабых мест системы или легко угадываемых секретных вопросов. </desc>
	<solution>Убедитесь, что все данные, вводимые пользователем в механизм восстановления пароля, тщательно отфильтрованы и проверены.

Не используйте стандартные слабые вопросы безопасности и используйте несколько вопросов безопасности. 

Убедитесь, что количество неправильных ответов на контрольный вопрос ограничено.  Отключите функцию восстановления пароля после определенного (небольшого) количества неверных угадываний. 

Требовать, чтобы пользователь правильно ответил на секретный вопрос перед сбросом пароля и отправкой нового пароля на адрес электронной почты записи. 

Никогда не позволяйте пользователю контролировать, на какой адрес электронной почты будет отправлен новый пароль в механизме восстановления пароля. 

Назначьте новый временный пароль вместо того, чтобы раскрывать исходный пароль. </solution>
	<reference>http://projects.webappsec.org/Insufficient-Password-Recovery</reference>
	<reference>http://cwe.mitre.org/data/definitions/640.html</reference>
</vuln_item_wasc_49>

</vulnerabilities>
